On Thu, 18 Sep 2025 10:50:11 +0200 Morten Brørup <m...@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.
