From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Matz Subject: Re: [RFC 00/14] prefix network structures Date: Fri, 26 Oct 2018 09:22:22 +0200 Message-ID: <20181026072222.6rz52dfqq3y2f6mv@platinum> References: <20181024081833.21432-1-olivier.matz@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dpdk-dev To: "Wiles, Keith" 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) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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