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 D055325B3 for ; Fri, 26 Oct 2018 09:20:19 +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 1gFwR5-0002Pp-0p; Fri, 26 Oct 2018 09:21:36 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Fri, 26 Oct 2018 09:20:15 +0200 Date: Fri, 26 Oct 2018 09:20:15 +0200 From: Olivier Matz To: Bruce Richardson Cc: dev@dpdk.org Message-ID: <20181026072015.ojjuoqnwsxlqcase@platinum> References: <20181024081833.21432-1-olivier.matz@6wind.com> <20181024163909.GA12444@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024163909.GA12444@bricha3-MOBL.ger.corp.intel.com> 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:20:20 -0000 Hi, On Wed, Oct 24, 2018 at 05:39:09PM +0100, Bruce Richardson wrote: > On Wed, Oct 24, 2018 at 10:18:19AM +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. > > > > Can you clarify a bit as to why we can't keep around compatibility versions > of the headers, alongside the new versions? I'm not following the logic > above. Can we not introduce completely new headers with the replacements > while leaving the old ones intact? This is something I tried to do, it is not in the RFC because it was not satisfying, but you can find it there: http://git.droids-corp.org/?p=dpdk.git;a=commitdiff;h=ba1e8e498306 With this patch, the usage of unprefixed structures, defines and functions in rte net is still possible by an external application, except if RTE_NET_NO_COMPAT is defined. However, functions and structures that are not in librte_net (the examples from my previous mail, quoted above) use the rte_ prefixed structures in their prototypes. For instance, an application that use rte_eth_macaddr_get() will no compile anymore because it will pass a (struct ether_addr *) instead of a (struct rte_ether_addr *). I don't see any good mean to fix this. Maybe we can do something with defines, but I don't think it is possible to provide both APIs for functions like rte_eth_macaddr_get(). I'm also not convinced it will be that helpful. At the end, if the patchset is applied, we want the applications to switch to the new API. To ease the transition, we can provide a script to patch an application, very similar to the one I use to generate the patchset. Olivier