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 988485424 for ; Fri, 26 Oct 2018 09:22:25 +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 1gFwT8-0002QA-Hs; Fri, 26 Oct 2018 09:23:44 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Fri, 26 Oct 2018 09:22:22 +0200 Date: Fri, 26 Oct 2018 09:22:22 +0200 From: Olivier Matz To: "Wiles, Keith" Cc: dpdk-dev Message-ID: <20181026072222.6rz52dfqq3y2f6mv@platinum> References: <20181024081833.21432-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:22:25 -0000 Hi, On Wed, Oct 24, 2018 at 02:56:14PM +0000, Wiles, Keith wrote: > > > > On Oct 24, 2018, at 1:18 AM, 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? > > I did not see the deprecation notice in the patches below, but I could have missed it. I will send it only if we reach a consensus about the need to apply the patchset. Regards Olivier