> > > > From: Thomas Monjalon [mailto:tho...@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?
