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

[Neil Horman]

On Fri, Mar 23, 2018 at 05:00:34PM +0000, Bruce Richardson wrote:
> 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).
> 
I would be 1000% on board with this conversion.

Best
Neil