Re: mbuf fast-free requirements analysis

Stephen Hemminger
2026-01-13T16:08:08Z

On Tue, 13 Jan 2026 14:48:19 +0000
Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote:

> > > > > > >
> > > > > > > __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.
> >
> I understand your point lads, and somewhat agree: if we plan to keep FAST_FREE flag forever,
> then it is probably the simplest and safest approach.
> My hope was that such function will open a possibility for the PMDs to implement similar
> perf improvement completely transparent to the user (without need for special flags and/or pre-requirements).
> But might be I am looking forward way too far with it.
> Even what Morten proposed above is a big step, so ok - let's deal with it first.
> Konstantin
>

We should document any restrictions on this and other semantic assumptions.
Ideally, then AI review tools could help new and old developers see places
where the assumptions are violated.