Re: [dpdk-dev] [RFC 00/14] prefix network structures

[Olivier Matz <olivier.matz@6wind.com>]

Hi,

On Wed, Oct 24, 2018 at 05:39:09PM +0100, Bruce Richardson wrote:
> On Wed, Oct 24, 2018 at 10:18:19AM +0200, Olivier Matz wrote:
> > This RFC targets 19.02.
> > 
> > The rte_net headers conflict with the libc headers, because
> > some definitions are duplicated, sometimes with few differences.
> > This was discussed in [1], and more recently at the techboard.
> > 
> > Before sending the deprecation notice (target for this is 18.11),
> > here is a draft that can be discussed.
> > 
> > This RFC adds the rte_ (or RTE_) prefix to all structures, functions
> > and defines in rte_net library. This is a big changeset, that will
> > break the API of many functions, but not the ABI.
> > 
> > One question I'm asking is how can we manage the transition.
> > Initially, I hoped it was possible to have a compat layer during
> > one release (supporting both prefixed and unprefixed names), but
> > now that the patch is done, it seems the impact is too big, and
> > impacts too many libraries.
> > 
> > Few examples:
> >   - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
> >   - many rte_flow structures use the rte_ prefixed net structures
> >   - the mac field of virtio_net structure is rte_ether_addr
> >   - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
> >   ...
> > 
> > Therefore, it is clear that doing this would break the compilation
> > of many external applications.
> > 
> 
> Can you clarify a bit as to why we can't keep around compatibility versions
> of the headers, alongside the new versions? I'm not following the logic
> above. Can we not introduce completely new headers with the replacements
> while leaving the old ones intact?

This is something I tried to do, it is not in the RFC because it was
not satisfying, but you can find it there:

http://git.droids-corp.org/?p=dpdk.git;a=commitdiff;h=ba1e8e498306

With this patch, the usage of unprefixed structures, defines and
functions in rte net is still possible by an external application,
except if RTE_NET_NO_COMPAT is defined.

However, functions and structures that are not in librte_net (the
examples from my previous mail, quoted above) use the rte_ prefixed
structures in their prototypes. For instance, an application that use
rte_eth_macaddr_get() will no compile anymore because it will pass
a (struct ether_addr *) instead of a (struct rte_ether_addr *).

I don't see any good mean to fix this. Maybe we can do something with
defines, but I don't think it is possible to provide both APIs for
functions like rte_eth_macaddr_get(). I'm also not convinced it will be
that helpful. At the end, if the patchset is applied, we want the
applications to switch to the new API. To ease the transition, we can
provide a script to patch an application, very similar to the one I use
to generate the patchset.

Olivier