On Mon, Dec 22, 2025 at 06:11:35PM +0100, Morten Brørup wrote: > > From: Konstantin Ananyev [mailto:[email protected]] > > 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
