mbuf fast-free requirements analysis

[Bruce Richardson]

On Mon, Dec 22, 2025 at 06:11:35PM +0100, Morten Brørup wrote:
> > From: Konstantin Ananyev [mailto:konstantin.ananyev at huawei.com]
> > Sent: Monday, 22 December 2025 16.22
> > > > > > >

<snip>

> > > > >
> > > > > 	__rte_mbuf_raw_sanity_check_mp(m, mp);
> > > > > 	rte_mbuf_history_mark(mbuf,
> > > > > RTE_MBUF_HISTORY_OP_LIB_PREFREE_RAW);
> > > > > }
> > > >
> > > > Thanks Morten, though should we really panic if condition is not
> > met?
> > > > Might be just do check first and return an error.
> > >
> > > __rte_mbuf_raw_sanity_check_mp() is a no-op unless
> > > RTE_LIBRTE_MBUF_DEBUG is enabled.
> > 
> > Yep, I noticed.
> > 
> > >
> > > Using it everywhere in alloc/free in the mbuf library is the
> > convention.
> > >
> > > And if we don't do it here, the __rte_mbuf_raw_sanity_check_mp() in
> > > rte_mbuf_raw_free() will panic later instead.
> > 
> > Why?
> > This new routine (rte_mbuf_raw_prefree_seg) can check that mbuf
> > satisfies fast-free criteria
> > before updating it, and if conditions are not met simply return an
> > error.
> > Then the driver has several options:
> > 1) Drop the packet silently
> > 2) Refuse to send it
> > 3) Switch to some slower but always working code-path (without fast-
> > free)
> > 4) Panic
> 
> It boils down to purpose.
> 
> The function is designed for use in the transmit code path designated for fast-free, where the application has promised/hinted that packets are fast-free compliant.
> Violating preconditions in the fast path (by passing packets not compliant to fast-free requirements to this function) is a serious type of bug, for which DPDK usually doesn't provide graceful fallback.
> I don't want to make an exception (and introduce graceful fallback) for the designated fast-free code path.
> 
> My answer would be completely different if we were designing an API for standard packet transmission, whereby some packets living up to certain criteria could take a faster code path for being freed.
> If that was the case, I would agree with you about returning a value to indicate how to proceed, like rte_pktmbuf_prefree_seg() does.
> 
I would tend to agree. The extra handling for those cases just expands the
code and adds more potential branches to the resulting binary. Lots of the
fastpath code just assumes you know what you are doing, and violating
constraints will lead to panics and segfaults generally. Therefore panicing
in this case doesn't seem a bit deal to me.

/Bruce