DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Ray Kinsella <mdr@ashroe.eu>, Luca Boccassi <bluca@debian.org>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
	Eelco Chaudron <echaudro@redhat.com>,
	dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>,
	David Marchand <david.marchand@redhat.com>,
	Ian Stokes <ian.stokes@intel.com>
Subject: Re: [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal
Date: Sat, 15 Feb 2020 08:43:49 -0500	[thread overview]
Message-ID: <20200215134349.gqlulelgihpzchef@penguin.lxd> (raw)
In-Reply-To: <20200214215253.GA857@bricha3-MOBL.ger.corp.intel.com>

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
> 

  reply	other threads:[~2020-02-15 13:44 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 12:29 Ferruh Yigit
2020-01-29 14:46 ` Bruce Richardson
2020-01-29 14:57 ` Andrzej Ostruszka
2020-01-29 16:25   ` Ferruh Yigit
2020-01-29 16:30     ` Andrzej Ostruszka
2020-01-29 16:40       ` Ferruh Yigit
2020-01-29 16:43 ` [dpdk-dev] [RFC v2] " Ferruh Yigit
2020-01-29 17:49   ` Andrzej Ostruszka
2020-01-30 12:33   ` Thomas Monjalon
2020-01-30 12:57     ` Luca Boccassi
2020-01-30 14:17       ` Thomas Monjalon
2020-01-30 14:21         ` Luca Boccassi
2020-01-30 15:55           ` Thomas Monjalon
2020-01-30 16:04             ` Luca Boccassi
2020-01-30 16:15               ` Eelco Chaudron
2020-01-30 20:20                 ` Thomas Monjalon
2020-02-03 11:10                   ` Eelco Chaudron
2020-01-31  9:25     ` Ferruh Yigit
2020-05-13 12:11   ` [dpdk-dev] [PATCH] meter: provide experimental alias of API for old apps Ferruh Yigit
2020-05-13 16:30     ` Thomas Monjalon
2020-05-13 17:37       ` Ferruh Yigit
2020-05-13 18:05     ` [dpdk-dev] [PATCH v2] " Ferruh Yigit
2020-05-14  8:44       ` Ray Kinsella
2020-05-14 11:53         ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2020-05-14 11:52     ` [dpdk-dev] [PATCH v3] " Ferruh Yigit
2020-05-14 15:10       ` Ray Kinsella
2020-05-14 15:32       ` David Marchand
2020-05-14 15:56         ` Ray Kinsella
2020-05-14 16:07         ` Ferruh Yigit
2020-05-14 16:30           ` David Marchand
2020-05-14 16:11     ` [dpdk-dev] [PATCH v4] " Ferruh Yigit
2020-05-15 13:31       ` Thomas Monjalon
2020-05-15 14:41         ` Ray Kinsella
2020-05-15 15:03         ` Ray Kinsella
2020-05-15 14:36       ` [dpdk-dev] [PATCH v5] abi: " Ray Kinsella
2020-05-15 15:01       ` [dpdk-dev] [PATCH v6] " Ray Kinsella
2020-05-16 11:53         ` Neil Horman
2020-05-18 17:18           ` Thomas Monjalon
2020-05-18 17:34             ` Ferruh Yigit
2020-05-18 17:51               ` Thomas Monjalon
2020-05-18 18:32                 ` Ferruh Yigit
2020-05-19 14:13                   ` Ray Kinsella
2020-05-19 14:14             ` Ray Kinsella
2020-05-17 19:52       ` [dpdk-dev] [PATCH v4] meter: " Dumitrescu, Cristian
2020-05-18  6:29         ` Ray Kinsella
2020-05-18  9:22           ` Thomas Monjalon
2020-05-18  9:30             ` Ray Kinsella
2020-05-18 10:46               ` Thomas Monjalon
2020-05-18 11:18                 ` Dumitrescu, Cristian
2020-05-18 11:49                   ` Ray Kinsella
2020-05-18 11:48                 ` Ray Kinsella
2020-05-18 12:13                   ` Thomas Monjalon
2020-05-18 13:06                     ` Ray Kinsella
2020-05-18 18:30     ` [dpdk-dev] [PATCH v5] " Ferruh Yigit
2020-05-19 12:16     ` [dpdk-dev] [PATCH v6] " Ferruh Yigit
2020-05-19 13:26       ` Dumitrescu, Cristian
2020-05-19 14:24         ` Thomas Monjalon
2020-05-19 14:22       ` Ray Kinsella
2020-02-02 18:53 ` [dpdk-dev] [RFC] meter: fix ABI break due to experimental tag removal Neil Horman
2020-02-03 12:53   ` Ferruh Yigit
2020-02-04 12:02     ` Neil Horman
2020-02-05 10:04       ` Luca Boccassi
2020-02-05 11:32         ` Neil Horman
2020-02-13 17:40           ` Ray Kinsella
2020-02-14  2:40             ` Neil Horman
2020-02-14 11:36               ` Bruce Richardson
2020-02-14 20:48                 ` Neil Horman
2020-02-14 21:52                   ` Bruce Richardson
2020-02-15 13:43                     ` Neil Horman [this message]
2020-02-17 14:23                   ` Ray Kinsella
2020-02-17 15:37                     ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200215134349.gqlulelgihpzchef@penguin.lxd \
    --to=nhorman@tuxdriver.com \
    --cc=bluca@debian.org \
    --cc=bruce.richardson@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=echaudro@redhat.com \
    --cc=ferruh.yigit@intel.com \
    --cc=ian.stokes@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).