From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <bruce.richardson@intel.com> Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 42469160 for <dev@dpdk.org>; Fri, 26 Oct 2018 12:15:18 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 03:15:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,427,1534834800"; d="scan'208";a="102862201" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by orsmga001.jf.intel.com with SMTP; 26 Oct 2018 03:15:15 -0700 Received: by (sSMTP sendmail emulation); Fri, 26 Oct 2018 11:15:14 +0100 Date: Fri, 26 Oct 2018 11:15:14 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Olivier Matz <olivier.matz@6wind.com> Cc: dev@dpdk.org Message-ID: <20181026101514.GB14620@bricha3-MOBL.ger.corp.intel.com> References: <20181024081833.21432-1-olivier.matz@6wind.com> <20181024163909.GA12444@bricha3-MOBL.ger.corp.intel.com> <20181026072015.ojjuoqnwsxlqcase@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181026072015.ojjuoqnwsxlqcase@platinum> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 26 Oct 2018 10:15:18 -0000 On Fri, Oct 26, 2018 at 09:20:15AM +0200, Olivier Matz wrote: > 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. > Out of interest, about how many non rte_net functions are we talking about here?