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

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Oct 26, 2018 at 09:20:15AM +0200, Olivier Matz wrote:
> 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.
> 

Out of interest, about how many non rte_net functions are we talking about here?