From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com [209.85.215.194]) by dpdk.org (Postfix) with ESMTP id 5581C1BDED for ; Fri, 21 Dec 2018 00:48:38 +0100 (CET) Received: by mail-pg1-f194.google.com with SMTP id g189so1604792pgc.5 for ; Thu, 20 Dec 2018 15:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zVS57XebgtiPVLHqmpFKyIunCQUW4pdtRH2CyD9tUN8=; b=1Ff2ue8G0zPAkzBwjwTmUqwtrCtgWytXtgREUb5hCU4DaX3wbyiKWRas+rcKXfclsA 8xSppSmivD7R+5itSq8eWfrE+JwtM6uE13YomDd7/Ji04bnyGRteT930m941EIw1SMPD uc82l+ahBxMTVS22uspG9gYklRBcRlr/xRuS66i8GEWmtLw+a4qS3zHwJbc41q7JAe7h LpoyNV9lux8lJJ1sLtaCE4VsD0Wrc9U17HnWrDWb2f1FFDHxE/nYdvrMwu1hfam3WTrx dBKYPFCG00xEmDb8+J7gIzf009QmQ5hnCUOJKvCzMVQI2Kwdme2J8AMRfzYqOrUcyZTm As5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zVS57XebgtiPVLHqmpFKyIunCQUW4pdtRH2CyD9tUN8=; b=bf9vOvQd+qfOIMN1hDD9hUMoXpVIugS+723Y0D1ejtq3FPHoyv217sBH7MQrUIIo42 kVlpzozHFUr1qyFgL/+uxzqht8TQLdPx4FV69UoD3PIgYJeyqAj/0mNQqWPwf898cXgl 9l3RILsVW/ZRI8T4q99lz5ru/9ZTfChNYOTtna7ShrhneafT2HweNq23GXnSYtXGGaKh DGubmmOQT3L2TPeZNVQASKTS7amY9qtDIklKY+adsBhbURQM3Z6VRfo/bRMGpcOLQZxe S60ZZDCI7nzuv/qflA3hLAWkJTxlXN3kLmE9xKgQHD4H9LeZsnl8z02RrQDZ63vsQpuk UJ7g== X-Gm-Message-State: AA+aEWZHrwWvi3re20ZjMyNbq7Hs6V91hhQ7KmbkYJbWxo/q243Hjz3k XE6xdwfDNFR4X/cJ0AQAtQ1P/KZbYOk= X-Google-Smtp-Source: AFSGD/VRQUPpj+uqOpwBMrx2yhkfnvnf/K+zw3rch/sZh03A8IGXBUBsdZjnVab+Q5ySRlexCci7qA== X-Received: by 2002:a62:d148:: with SMTP id t8mr260768pfl.52.1545349717360; Thu, 20 Dec 2018 15:48:37 -0800 (PST) Received: from xeon-e3 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id w136sm31567705pfd.169.2018.12.20.15.48.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 20 Dec 2018 15:48:37 -0800 (PST) Date: Thu, 20 Dec 2018 15:48:34 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: Olivier MATZ , dpdk-dev , Keith Wiles , Bruce Richardson Message-ID: <20181220154834.166aedb6@xeon-e3> In-Reply-To: References: <20181024081833.21432-1-olivier.matz@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 20 Dec 2018 23:48:38 -0000 On Thu, 20 Dec 2018 21:59:37 +0000 Ferruh Yigit wrote: > On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (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? > > Is there an consensus about the patchset? There was a decision on techboard to > go with this change (adding rte_ prefix) [1]. > > > This is something that will affect DPDK consumers. Since many APIs are changing > most probably will break API compatibility for many libraries. > > Meanwhile the conflict with the libc headers mentioned a few times in the past, > this is something we need to fix. > > 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. > > 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 think a > deprecation notice is not merged for this change in 18.11 scope.) > > With the prediction of 19.05 will be big and already break API/ABI for some > libraries, can we push this into 19.05 as an early merge into repo? > > And I think this patch will affect LTS releases and will break auto backporting > for many fixes because it touches many places, so pushing this change even to > next LTS (19.11) can be an option. > > > Olivier, Thomas, > > What do you think about postponing this to 19.05 or even 19.11 ? > > > > [1] > https://mails.dpdk.org/archives/dev/2018-October/116695.html > > > > > > > Things that are missing in RFC: > > - test with FreeBSD > > - manually fix some indentation issues > > > > > > 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 > > 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. 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. 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.