[dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half

[Ananyev, Konstantin]

> > > > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > > > Sent: Saturday, November 7, 2020 4:53 PM
> > > >
> > > > The mempool pointer in the mbuf struct is moved
> > > > from the second to the first half.
> > > > It should increase performance on most systems having 64-byte cache line,
> > > > i.e. mbuf is split in two cache lines.
> > >
> > > Perhaps with the #define DEV_TX_OFFLOAD_MBUF_FAST_FREE mentioned by Konstantin, it might be better moving m->next instead, at
> > least for applications with the opportunity to set this flag (e.g. applications with only one mbuf pool).
> > >
> > > Unfortunately, the information about the DEV_TX_OFFLOAD_MBUF_FAST_FREE flag came to light after the techboard meeting, and I
> > don't have any benchmarks to support this suggestion, so I guess it's hard to change the techboard's decision to move the pool pointer.
> > >
> >
> > The thing with FAST_FREE is that it doesn't just indicate that there is
> > only one mbuf pool, but rather that none of the packets are chained mbufs
> > either.
> 
> Hmm, wonder where such assumption comes from?
> There is nothing about forbidding chained mbufs in rte_ethdev.h right now:
> #define DEV_TX_OFFLOAD_MBUF_FAST_FREE   0x00010000
> /**< Device supports optimization for fast release of mbufs.
>  *   When set application must guarantee that per-queue all mbufs comes from
>  *   the same mempool and has refcnt = 1.
>  */
> 
> > Therefore, the flag applies equally to both next and pool pointers
> > for optimization. [And the flag should perhaps be two flags!]
> >
> 
> I think what Morten means here:
> For FAST_FREE PMD can store pool pointer somewhere in its queue metadata
> and doesn't need to read it from the mbuf.
> So if we move next to first line - mbuf_free code-path for FAST_FREE case can
> avoid touching  second cache line in the mbuf.

Just as a different thought:
if we move 'next' to the first cache line, can we get rid of 'nb_segs' field completely?