From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [RFC 00/14] prefix network structures Date: Fri, 21 Dec 2018 14:38:31 +0000 Message-ID: <28E73175-3924-49B0-A88A-E52C65D05C65@intel.com> References: <20181024081833.21432-1-olivier.matz@6wind.com> <20181220154834.166aedb6@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Yigit, Ferruh" , Olivier MATZ , dpdk-dev , "Richardson, Bruce" To: Stephen Hemminger Return-path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id E1FA81BE43 for ; Fri, 21 Dec 2018 15:38:32 +0100 (CET) In-Reply-To: <20181220154834.166aedb6@xeon-e3> Content-Language: en-US Content-ID: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Dec 20, 2018, at 5:48 PM, Stephen Hemminger wrote: >=20 > On Thu, 20 Dec 2018 21:59:37 +0000 > Ferruh Yigit wrote: >=20 >> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote: >>> This RFC targets 19.02. >>>=20 >>> 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. >>>=20 >>> Before sending the deprecation notice (target for this is 18.11), >>> here is a draft that can be discussed. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 *) >>> ... >>>=20 >>> Therefore, it is clear that doing this would break the compilation >>> of many external applications. >>>=20 >>> 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. >>>=20 >>> While it is obviously better to have a good namespace convention,=20 >>> we need to identify the issues we have today before deciding it's >>> worth doing the change. >>>=20 >>> Comments? =20 >>=20 >> Is there an consensus about the patchset? There was a decision on techbo= ard to >> go with this change (adding rte_ prefix) [1]. >>=20 >>=20 >> This is something that will affect DPDK consumers. Since many APIs are c= hanging >> most probably will break API compatibility for many libraries. >>=20 >> Meanwhile the conflict with the libc headers mentioned a few times in th= e past, >> this is something we need to fix. >>=20 >> There are a few comments reluctant to this big modification, but what I >> understand from Olivier's response both using BSD defines or having >> compatibility headers in DPDK won't solve the problem completely. >>=20 >> And assuming we will continue with this solution, another question is do= we >> still want to push in 19.02 scope? (And from process point of view I thi= nk a >> deprecation notice is not merged for this change in 18.11 scope.) >>=20 >> With the prediction of 19.05 will be big and already break API/ABI for s= ome >> libraries, can we push this into 19.05 as an early merge into repo? >>=20 >> And I think this patch will affect LTS releases and will break auto back= porting >> for many fixes because it touches many places, so pushing this change ev= en to >> next LTS (19.11) can be an option. >>=20 >>=20 >> Olivier, Thomas, >>=20 >> What do you think about postponing this to 19.05 or even 19.11 ? >>=20 >>=20 >>=20 >> [1] >> https://mails.dpdk.org/archives/dev/2018-October/116695.html >>=20 >>>=20 >>>=20 >>> Things that are missing in RFC: >>> - test with FreeBSD >>> - manually fix some indentation issues >>>=20 >>>=20 >>> 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 =20 >>=20 >>=20 >=20 > Sigh. Another case where DPDK has to reinvent something because > we can't figure out how to do dependent libraries correctly. > I would have rather just using the existing Linux, BSD definitions > and fixing the DPDK code. >=20 > It is probably the only viable compromise, but it adds to long > term maintenance, and breaks DPDK applications. Neither of which > is a good thing. >=20 > Should this be done by marking the old structure deprecated > first? Ideally, spread over three releases: first, tell the users > in the documentation it is coming; second, mark the old structures > as deprecated causing compiler warnings; third, remove the old > definitions. Doing at once is introducing user pain for no gain. +1 Regards, Keith