> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Monday, November 9, 2020 11:09 AM > > On Sat, Nov 07, 2020 at 07:57:05PM +0100, Morten Brørup wrote: > > > 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. Therefore, the flag applies equally to both next and pool > pointers > for optimization. [And the flag should perhaps be two flags!]
I guess we could offer the same optimization to applications by adding a rte_mbuf_raw_free_bulk() function to the mbuf library. I will put that on my ToDo-list. :-)
