Re: Fixing MBUF_FAST_FREE TX offload requirements?

[Nithin Dabilpuram <nithind1988@gmail.com>]

I agree with Stephen.
Generally what we see with customers is they enable multi-seg offload
on Rx and Tx just to handle very few jumbo frames while most of the
pkts are smaller / IMIX.
So if we say FAST_FREE is mutually exclusive with MULTI_SEGS offload,
then in effect, FAST_FREE is never used.

We should restore to original two requirements and report bugs in
driver as bugs rather than adjusting the spec for that.
In Marvell drivers, we have adhered to original spec. Keeping #3 is
fine IMO. Problem is only with #4.

--
Nithin

PS: Sorry for late reply

On Thu, Sep 18, 2025 at 8:49 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> 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.
>