Re: Fixing MBUF_FAST_FREE TX offload requirements?

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 18 Sep 2025 10:50:11 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> Dear NIC driver maintainers (CC: DPDK Tech Board),
> 
> The DPDK Tech Board has discussed that patch [1] (included in DPDK 25.07) extended the documented requirements to the RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE offload.
> These changes put additional limitations on applications' use of the MBUF_FAST_FREE TX offload, and made MBUF_FAST_FREE mutually exclusive with MULTI_SEGS (which is typically used for jumbo frame support).
> The Tech Board discussed that these changes do not reflect the intention of the MBUF_FAST_FREE TX offload, and wants to fix it.
> Mainly, MBUF_FAST_FREE and MULTI_SEGS should not be mutually exclusive.
> 
> The original RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE requirements were:
> When set, application must guarantee that
> 1) per-queue all mbufs come from the same mempool, and
> 2) mbufs have refcnt = 1.
> 
> The patch added the following requirements to the MBUF_FAST_FREE offload, reflecting rte_pktmbuf_prefree_seg() postconditions:
> 3) mbufs are direct,
> 4) mbufs have next = NULL and nb_segs = 1.
> 
> Now, the key question is:
> Can we roll back to the original two requirements?
> Or do the drivers also depend on the third and/or fourth requirements?

IMHO fast free should be as much like normal as possible.
Only things that would have a measurable impact on performance would help.

The reason for the single mempool is mostly related to not requiring code
that would walk a multi-segment mbuf to disperse the segments to potentially
different pools.

The reason for the refcnt == 1 is that updating refcnt requires atomic
operations which need to read-modify-write on memory (not just cache).
And RMW operation can take several memory clock cycles.