On Tue, 13 Jan 2026 14:48:19 +0000 Konstantin Ananyev <[email protected]> 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.
