From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2018 06:38:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,381,1539673200"; d="scan'208";a="120244392" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 21 Dec 2018 06:38:31 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Dec 2018 06:38:31 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.209]) by FMSMSX155.amr.corp.intel.com ([169.254.5.119]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 06:38:31 -0800 From: "Wiles, Keith" To: Stephen Hemminger CC: "Yigit, Ferruh" , Olivier MATZ , dpdk-dev , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [RFC 00/14] prefix network structures Thread-Index: AQHUa3JYXtpHI68SckKJ7JaBzS/mMqWJDdCAgAAecQCAAPimgA== 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> In-Reply-To: <20181220154834.166aedb6@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.153.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 21 Dec 2018 14:38:33 -0000 > 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