[dpdk-dev] [PATCH v5] ethdev: return named opaque type instead of void pointer

Bruce Richardson bruce.richardson at intel.com
Fri Mar 23 18:00:34 CET 2018


On Wed, Mar 21, 2018 at 09:04:01AM -0400, Neil Horman wrote:
> On Tue, Mar 20, 2018 at 04:34:04PM +0000, Ferruh Yigit wrote:
> > "struct rte_eth_rxtx_callback" is defined as internal data structure and
> > used as named opaque type.
> > 
> > So the functions that are adding callbacks can return objects in this
> > type instead of void pointer.
> > 
> > Also const qualifier added to "struct rte_eth_rxtx_callback *" to
> > protect it better from application modification.
> > 
> > Signed-off-by: Ferruh Yigit <ferruh.yigit at intel.com>
> > ---
> > v2:
> > * keep using struct * in parameters, instead add callback functions
> > return struct rte_eth_rxtx_callback pointer.
> > 
> > v4:
> > * Remove deprecation notice. LIBABIVER already increased in this release
> > 
> > v5:
> > * add const qualifier to rte_eth_rxtx_callback
> I still wish we could find a way to remove the inline functions and truly
> protect that struct, but a const is definately better than nothing
> 
> Acked-by: Neil Horman <nhorman at tuxdriver.com>
> 
Actually, I think we should do exactly that - convert the rx and tx burst
calls into actual function calls (and consider any other inlined functions
too). The cost would be the overhead of making an additional function call
per-burst, which is likely to be pretty minimal for most common burst sizes
e.g. 32.

We did some quick tests here with the i40e driver, and for a burst size of
32 saw less than 1% perf drop, and for even a small burst of 8 saw less
than 5% drop. Note that this is testing with testpmd, which has nothing but
I/O in the datapath. A real-world app is likely to do far more with the
packets and therefore see proportionally far less perf hit.

Thoughts?

/Bruce

PS: This un-inlining could probably be applied to other device types too,
e.g. cryptodev (though probably not eventdev as it tends to have smaller
bursts in some use-cases).


More information about the dev mailing list