From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 930EC4F94 for ; Fri, 26 Oct 2018 09:56:07 +0200 (CEST) Received: from rsa59-2-82-233-193-189.fbx.proxad.net ([82.233.193.189] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gFwzk-0002TO-4A; Fri, 26 Oct 2018 09:57:25 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Fri, 26 Oct 2018 09:56:04 +0200 Date: Fri, 26 Oct 2018 09:56:04 +0200 From: Olivier Matz To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20181026075604.a3eqdqp5mxwydh6x@platinum> References: <20181024081833.21432-1-olivier.matz@6wind.com> <20181024113812.3318eb54@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024113812.3318eb54@xeon-e3> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [RFC 00/14] prefix network structures X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 07:56:07 -0000 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 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