Re: mbuf fast-free requirements analysis

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jan 14, 2026 at 07:05:44PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 14 January 2026 17.36
> > 
> > On Wed, Jan 14, 2026 at 04:31:31PM +0100, Morten Brørup wrote:
> > > > > If I'm not mistaken, the mbuf library is not a barrier for fast-
> > > > freeing
> > > > > segmented packet mbufs, and thus fast-free of jumbo frames is
> > > > possible.
> > > > >
> > > > > We need a driver developer to confirm that my suggested approach
> > -
> > > > > resetting the mbuf fields, incl. 'm->nb_segs' and 'm->next', when
> > > > > preparing the Tx descriptor - is viable.
> > > > >
> > > > Excellent analysis, Morten. If I get a chance some time this
> > release
> > > > cycle,
> > > > I will try implementing this change in our drivers, see if any
> > > > difference
> > > > is made.
> > >
> > > Bruce,
> > >
> > > Have you had a chance to look into the driver change requirements?
> > > If not, could you please try scratching the surface, to build a gut
> > feeling.
> > 
> > I'll try and take a look this week. Juggling a few things at the
> > moment, so
> > I had forgotten about this. Sorry.
> > 
> > More comments inline below.
> > 
> > /Bruce
> > 
> > >
> > > I wonder if the vector implementations have strong requirements that
> > packets are not segmented...
> > >
> > > The i40 driver only sets "tx_simple_allowed" and "tx_vec_allowed"
> > flags when MBUF_FAST_FREE is set:
> > >
> > https://elixir.bootlin.com/dpdk/v25.11/source/drivers/net/intel/i40e/i4
> > 0e_rxtx.c#L3502
> > >
> > 
> > Actually, it allows but does not require FAST_FREE. The check is just
> > verifying that the flags with everything *but* FAST_FREE masked out is
> > the
> > same as the original flags, i.e. FAST_FREE is just ignored.
> 
> That's not how I read the code:
> ad->tx_simple_allowed =
> 	(txq->offloads ==
> 	 (txq->offloads & RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE) &&
> 	 txq->tx_rs_thresh >= I40E_TX_MAX_BURST);
> 
> Look at it with offloads=(MULTI_SEGS|FAST_FREE):
> simple_allowed = (MULTI_SEGS|FAST_FREE) == (MULTI_SEGS|FAST_FREE) & FAST_FREE
> i.e.:
> simple_allowed = (MULTI_SEGS|FAST_FREE) == FAST_FREE
> i.e.: false
> 

Which is correct. The only flag allowed is FAST_FREE, but its not required.
If the input flags were just MULTI_SEGS, it would end  up as:

simple_allowed = (MULTI_SEGS) == 0
i.e. also false

So the FAST_FREE flag does not affect the result.

/Bruce