[dpdk-dev] RFC: hiding struct rte_eth_dev

[Bruce Richardson]

On Mon, Sep 23, 2019 at 05:19:27PM +0100, Ray Kinsella wrote:
> Hi folks,
> 
> The ABI Stability proposals should be pretty well known at this point.
> The latest rev is here ...
> 
> http://inbox.dpdk.org/dev/1565864619-17206-1-git-send-email-mdr@ashroe.eu/
> 
> As has been discussed public data structure's are risky for ABI
> stability, as any changes to a data structure can change the ABI. As a
> general rule you want to expose as few as possible (ideally none), and
> keep them as small as possible.
> 
> One of the key data structures in DPDK is `struct rte_eth_dev`. In this
> case, rte_eth_dev is exposed public-ally, as a side-effect of the
> inlining of the [rx,tx]_burst functions.
> 
> Marcin Zapolski has been looking at what to do about it, with no current
> consensus on a path forward. The options on our table is:-
> 
> 1. Do nothing, live with the risk to DPDK v20 ABI stability.
> 
> 2. Pad rte_eth_dev, add some extra bytes to the structure "in case" we
> need to add a field during the v20 ABI (through to 20.11).
> 
> 3. Break rte_eth_dev into public and private structs.
>   - See
> http://inbox.dpdk.org/dev/20190906131813.1343-1-marcinx.a.zapolski@intel.com/
>   - This ends up quiet an invasive patch, late in the cycle, however it
> does have no performance penalty.
> 
> 4. Uninline [rx,tx]_burst functions
>  -  See
> http://inbox.dpdk.org/dev/20190730124950.1293-1-marcinx.a.zapolski@intel.com/
>  - This has a performance penalty of ~2% with testpmd, impact on a "real
> workload" is likely to be in the noise.
> 
> We need to agree an approach for v19.11, and that may be we agree to do
> nothing. My personal vote is 4. as the simplest with minimal impact.
> 
Thanks for calling out these potential options, Ray.

#4, uninlining, would also be my preference, though I think #1, do nothing,
is probably ok and could live with #2, adding padding, if others like the
idea. While #3, splitting structures, has advantages, I just dislike how
invasive it is, and don't think it's a good candidate for 19.11.

/Bruce