> > > > > >
> > > > > > __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
