From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 94F91A054E; Sat, 15 Feb 2020 14:44:06 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F54ADE3; Sat, 15 Feb 2020 14:44:05 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id C9E9C374 for ; Sat, 15 Feb 2020 14:44:03 +0100 (CET) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1j2xjS-0007vG-4z; Sat, 15 Feb 2020 08:43:50 -0500 Date: Sat, 15 Feb 2020 08:43:49 -0500 From: Neil Horman To: Bruce Richardson Cc: Ray Kinsella , Luca Boccassi , Ferruh Yigit , Cristian Dumitrescu , Eelco Chaudron , dev@dpdk.org, Thomas Monjalon , David Marchand , Ian Stokes Message-ID: <20200215134349.gqlulelgihpzchef@penguin.lxd> References: <20200202185334.GA6783@localhost.localdomain> <7beadbbd-bf0d-e545-d9bb-0e3ae8228b71@intel.com> <20200204120230.GA13754@hmswarspite.think-freely.org> <8eaaec5dedcfcf09ae69b15cc80ac1ff1a1f4a30.camel@debian.org> <20200205113245.GA17468@hmswarspite.think-freely.org> <20c7c2a7-54f7-996f-923a-82202ebc66eb@ashroe.eu> <20200214023820.ogc2neraxwwtolde@penguin.lxd> <20200214113634.GA853@bricha3-MOBL.ger.corp.intel.com> <20200214204848.GA27176@hmswarspite.think-freely.org> <20200214215253.GA857@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200214215253.GA857@bricha3-MOBL.ger.corp.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Feb 14, 2020 at 09:52:53PM +0000, Bruce Richardson wrote: > On Fri, Feb 14, 2020 at 03:48:48PM -0500, Neil Horman wrote: > > On Fri, Feb 14, 2020 at 11:36:34AM +0000, Bruce Richardson wrote: > > > On Thu, Feb 13, 2020 at 09:40:40PM -0500, Neil Horman wrote: > > > > On Thu, Feb 13, 2020 at 05:40:43PM +0000, Ray Kinsella wrote: > > > > > > > > > > > > > > > On 05/02/2020 11:32, Neil Horman wrote: > > > > > > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote: > > > > > >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote: > > > > > >>>> But if we can do the versioning in the master, LTS can backport it > > > > > >>>> and can have mature version of that API in LTS without breaking > > > > > >>>> the existing users. > > > > > >>>> > > > > > >>> > > > > > >>> But why bother? The only thing you've changed is the version > > > > > >>> tagging. Its ok to leave that alone in LTS, you just cant change > > > > > >>> it. > > > > > >>> > > > > > >>> Thats part of the burden of an LTS release, it will have some drift > > > > > >>> from the upstream head, because you have to keep things stable. So > > > > > >>> you stabilize the upstream ABI version for this API and just never > > > > > >>> backport it to the current LTS release. > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> A customer (OVS) explicitly and specifically requested backporting > > > > > >> the symbol change to 19.11, as they don't want to enable > > > > > >> experimental APIs in their releases. I replied that it would only be > > > > > >> acceptable with aliasing to keep compatibility, and Ferruh very > > > > > >> kindly did the work to implement that. > > > > > >> > > > > > > but, thats part of the agreement, no? You can't always have new > > > > > > features and stability at the same time. > > > > > > > > > > > > I get that this is an odd corner case, because strictly speaking you > > > > > > could waive the ABI change that libabigail is reporting, and most > > > > > > application users (like OVS) could get away with it, because their > > > > > > application does all the right things to make it ok, but I don't > > > > > > think you can make a decsion like this for all users based on the > > > > > > request of a single user. > > > > > > > > > > > > It seems like the right thing is for OVS to augment their build time > > > > > > configuration to allow developers to select the ability to use > > > > > > experimental apis at compile time, and then the decision is placed in > > > > > > the hands of end users. > > > > > > > > > > So this is not isolated case right ... it is common from API's to > > > > > graduate from experimental to mature, we _want_ that to happen, we > > > > > _want_ APIs to mature. > > > > > > > > > Sure, I can absolutely agree with that, though I would suggest that the > > > > maturity of the ABI is orthogonal to its labeling as such (more on that > > > > below) > > > > > > > > > I am worried what you are proposing will encourage a behavior whereby > > > > > maintainers to wait until the declaration of the next major ABI version > > > > > to make these symbol changes, causing these kinds of changes to queue > > > > > up for that release. > > > > > > > > > I think you're probably right about that, and would make the agrument > > > > that thats perfectly fine (again I'll clarify below) > > > > > > > > > And you would have to ask why? In the case of a reasonably mature API, > > > > > there will be no functional or signature change - its mature! So what > > > > > is the harm of providing an alias back to Experimental until the next > > > > > ABI version is declared? > > > > > > > > > From a philosophical standpoint, there is absoluely no harm, and I don't > > > > think anyone would disagree, the harm comes from the details of the > > > > implementation, as you've noted. > > > > > > > > > So while yes, you are 100% right - experimental mean no guarantees. > > > > > But if the API is baked, it is not going to change, so I don't see the > > > > > harm. > > > > > > > > > > We don't want the unnecessary triumph of policy over pragmatism. > > > > > > > > > I would make the converse argument here. While I agree that when an API > > > > is mature, theres no point in calling it experimental anymore, I would > > > > also suggest that, if an API is mature, and not expected to change, > > > > theres no harm in leaving its version tag as experimental for an LTS > > > > release. This is what I was referring to above. Once an application > > > > developer has done the work to integrate an API from DPDK into its > > > > application, that work is done. If the API remains stable, then I > > > > honestly don't know that they care that the version label is EXPERIMENTAL > > > > versus 20.11 or 20.05 or whatever. They care about the API being stable > > > > more so than its version label. As such, it seems....reasonable to me to > > > > have developers queue their migration of experimental APIs to official > > > > versioned APIs at the next major release deliniation point. > > > > > > > > I'd welcome counter arguments, but it seems pretty natural to me to make > > > > these sorts of changes at the major release mark. People using > > > > experimantal apis have already implicity agreed to manage changes to > > > > them, so if we just hold it stable in an LTS release (and don't update > > > > the version label), its just gravy for them. > > > > > > > The counter argument that I see is that while the experimental tag remains > > > in place the user has no way to know that an API is stable or not, and so > > > in many projects cannot use the API. If for example an API that is > > > experimental in 19.11 is unchanged through 20.05 at which point we decide > > > to promote it to stable. Once the change to the exp tag it is made, any > > > users of 19.11 can then see that it is an unchanged and now-stable ABI and > > > can start using it in their software, if they wish, without having to wait > > > for the 20.11 release. Changing the tag early allows ABIs to be potentially > > > used immediately. > > > > > > > I would agree with this, however, when using an LTS release, in my mind at > > least, part of the agreement there is you get stability in the fuctions that > > were declared stable at the time of release. I'm not sure there should be an > > expectation of additional stabilization within the lifetime of the release > > (thats really what the 12 month LTS release cycle is for, no)? You never have > > to wait more than a year for a new set of stable features. If you want faster > > feature integration than that, you can choose to enable the experimental API's > > and accept the benefits and drawbacks thereof. > > > > That said, if (as I understand it) the goal is to provide a mechanism to allow > > experimental features to be promoted to stable status, perhaps we can find a > > happy middle ground. What if we were to create a construct such as this: > > > > #pragma push_macro("ALLOW_EXPERIMENTAL_APIS") > > #undef ALLOW_EXPERIMENTAL_APIS > > void __rte_experimental func(...); > > #pragma pop_macro("ALLOW_EXPERIMENTAL_APIS") > > > > Such a consruct would allow the maintainer of an API to pseudo-promote an API > > from a experimental to stable status, at least so far as compilation would be > > concerned. Its messy and clunky, and it wouldn't change the function version at > > all, but the end result would be that: > > a) such a wraped experimental function would no longer issue a warning when used > > during compilation/linking > > and > > b) provide a semi-easy grepable pattern for application writers to look for when > > considering the use of an API that was previously experimental > > > > such a construct would have to be used very judiciously, in that once its > > implemented, the API has to be treated as stable, even though its 'excused' from > > the normal checking, but it could provide something of the more rapid promotion > > path being sought. > > > Sure it could work and does meet the end goal. I'm not really sure it's a > better solution than just promoting the function and putting in an alias > for it back to experimental, though. > It probably isn't, I was just trying to think of alternative implementations, that dont make life harder in keeping up with LTS maintenence. Neil > /Bruce >