[dpdk-dev] [RFC 00/14] prefix network structures
Olivier Matz
olivier.matz at 6wind.com
Fri Oct 26 09:56:04 CEST 2018
Hi Stephen,
On Wed, Oct 24, 2018 at 11:38:12AM -0700, Stephen Hemminger wrote:
> On Wed, 24 Oct 2018 10:18:19 +0200
> Olivier Matz <olivier.matz at 6wind.com> 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.
> >
> > Another drawback we need to take in account: it will make the
> > backport of patches more difficult, although this is something
> > that could be tempered by a script.
> >
> > While it is obviously better to have a good namespace convention,
> > we need to identify the issues we have today before deciding it's
> > worth doing the change.
> >
> > Comments?
> >
> >
> > Things that are missing in RFC:
> > - test with FreeBSD
> > - manually fix some indentation issues
> >
> >
> > Olivier Matz (14):
> > net: add rte prefix to arp structures
> > net: add rte prefix to arp defines
> > net: add rte prefix to ether structures
> > net: add rte prefix to ether functions
> > net: add rte prefix to ether defines
> > net: add rte prefix to esp structure
> > net: add rte prefix to gre structure
> > net: add rte prefix to icmp structure
> > net: add rte prefix to icmp defines
> > net: add rte prefix to ip structure
> > net: add rte prefix to ip defines
> > net: add rte prefix to sctp structure
> > net: add rte prefix to tcp structure
> > net: add rte prefix to udp structure
> >
>
> Since BSD structures are available on Linux and BSD why is DPDK reinventing?
> There is no value in doing that.
>From what I see, some structures or defines are a bit different in Linux
and FreeBSD. Examples:
/* Linux */
struct ether_addr
{
u_int8_t ether_addr_octet[ETH_ALEN];
} __attribute__ ((__packed__));
/* FreeBSD */
struct ether_addr {
u_char octet[ETHER_ADDR_LEN];
} __packed;
That's true the compat between Linux and FreeBSD is better than before
in glibc. For instance with 7011c2622fe3 ("Remove __FAVOR_BSD.") added
in 2013 (glibc 2.19). It seems that MUSL also supports BSD network
structures.
So, I agree that using BSD structure looks possible, at least for
ip/ip6/tcp/udp/icmp/... structures and defines. I think we would still
need to provide some network structures for less usual protocols.
The question is: are we confident that the support of network BSD
struct/defines/funcs is good enough in all libc we (will) want to use?
Since DPDK is a network software, it is not that odd to provide our
own network structures, because we will have control on them.
Olivier
More information about the dev
mailing list