Re: mbuf fast-free requirements analysis

Bruce Richardson
2026-01-14T17:45:20Z

On Wed, Jan 14, 2026 at 06:31:24PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, 14 January 2026 18.01
> >
> > On Mon, Dec 15, 2025 at 12:06:38PM +0100, Morten Brørup wrote:
> > > Executive Summary:
> > >
> > > My analysis shows that the mbuf library is not a barrier for fast-
> > freeing
> > > segmented packet mbufs, and thus fast-free of jumbo frames is
> > possible.
> > >
> > >
> > > Detailed Analysis:
> > >
> > > The purpose of the mbuf fast-free Tx optimization is to reduce
> > > rte_pktmbuf_free_seg() to something much simpler in the ethdev
> > drivers, by
> > > eliminating the code path related to indirect mbufs.
> > > Optimally, we want to simplify the ethdev driver's function that
> > frees the
> > > transmitted mbufs, so it can free them directly to their mempool
> > without
> > > accessing the mbufs themselves.
> > >
> > > If the driver cannot access the mbuf itself, it cannot determine
> > which
> > > mempool it belongs to.
> > > We don't want the driver to access every mbuf being freed; but if all
> > > mbufs of a Tx queue belong to the same mempool, the driver can
> > determine
> > > which mempool by looking into just one of the mbufs.
> > >
> >
> > <snip>
> >
> > >
> > > 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.
> > >
> >
> > Just to make sure I understand things correctly here, the suggestion to
> > prototype is:
> >
> > - When FAST_FREE flag is set:
> > - reset the m->nb_segs and m->next fields (if necessary) when
> > accessing
> > the mbuf to write the descriptor
> > - skip calling pre-free seg on cleanup and instead
> > - just free all buffers directly to the mempool
> >
> > Is that correct?
>
> Yes.
> If this can be done with multi-segment packets, we should be able to eliminate the single-segment requirement to FAST_FREE.
> (Unless something in the code that writes the descriptor requires single-segment to be super performant, as I suspected of vectorization.)
>

Yes, the vector paths do require single-segment, but there is a separate
offload flag for that [1]. That flag is part of the overall
vector/non-vector Tx flags check.

/Bruce

[1] https://github.com/DPDK/dpdk/blob/main/lib/ethdev/rte_ethdev.h#L1643