RE: [PATCH] net/i40e: Fast release optimizations

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Morten Brørup
> Sent: Thursday, 11 December 2025 22.45
> 
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 10 December 2025 18.01
> >
> > On Mon, Aug 11, 2025 at 02:47:17PM +0200, Morten Brørup wrote:
> > > > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > > > Sent: Tuesday, 24 June 2025 08.13
> > > >
> > > > When fast releasing mbufs, the mbufs are not accessed, so do not
> > prefetch
> > > > them.
> > > > This saves a mbuf load operation for each fast released TX mbuf.
> > > >
> > > > When fast release of mbufs is enabled for a TX queue, cache the
> > mbuf
> > > > mempool pointer in the TX queue structure.
> > > > This saves one mbuf load operation for each burst of fast
> released
> > TX
> > > > mbufs.
> > > >
> > > > The txep->mbuf pointer is not used after the mbuf has been freed,
> > so do
> > > > not reset the pointer.
> > > > This saves a txep store operation for each TX mbuf freed.
> > > >
> > > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > > ---
> > >
> > > After further consideration, I think this patch should be split in
> > two:
> > > 1. Remove superfluous code: prefetching mbufs and resetting txep-
> > >mbuf pointers.
> > > 2. Cache the mbuf mempool pointer for FAST_FREE.
> > >
> > Hi Morten,
> >
> > any plans for a new version of this patch (split or otherwise)? This
> is
> > popped up again on my list in patchwork and want to decide what to do
> > with
> > it for this release. :-)
> >
> > /Bruce
> 
> I'll give it another shot.
> 
> I took another look at it today, and it looks like the txep->mbuf (i.e.
> sw_ring[].mbuf) is used by other cleanup functions, so not NULL'ing it
> needs more detailed review.
> 
> Anyway, prefetching the mbufs is a complete waste for fast free, where
> the mbufs are not being accessed at all. So there's still something to
> gain here.
> 
> Also, my assumption that txq->offloads is hotter than txq->fast_free_mp
> seems not to hold either, so I'll play around with that too.
> 
> I'm considering sending a series of patches with very small steps, so
> the individual changes are easy to review.
> 
> -Morten

Turns out the "common" part of the Intel drivers entangles the i40e patch with other Intel drivers, so I sent a generic patch covering all of those, and marked this one as Superseded.

-Morten