[dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function

[Trahe, Fiona]

Gentle reminder that we still haven't come to a consensus about
whether ABI compatibility is required across quarterly releases or not.
See below.

> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe at intel.com>
> Sent: Friday, April 17, 2020 12:47 PM
> To: Ray Kinsella <mdr at ashroe.eu>; Thomas Monjalon <thomas at monjalon.net>; Richardson, Bruce
> <bruce.richardson at intel.com>
> Cc: dev at dpdk.org; Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>; Neil Horman
> <nhorman at tuxdriver.com>; Luca Boccassi <bluca at debian.org>; Kevin Traynor
> <ktraynor at redhat.com>; Yigit, Ferruh <ferruh.yigit at intel.com>; Trahe, Fiona
> <fiona.trahe at intel.com>
> Subject: RE: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function
> 
> Hi all,
> 
> > -----Original Message-----
> > From: Ray Kinsella <mdr at ashroe.eu>
> > Sent: Friday, April 17, 2020 11:34 AM
> > To: Thomas Monjalon <thomas at monjalon.net>; Richardson, Bruce <bruce.richardson at intel.com>
> > Cc: Trahe, Fiona <fiona.trahe at intel.com>; dev at dpdk.org; Kusztal, ArkadiuszX
> > <arkadiuszx.kusztal at intel.com>; Neil Horman <nhorman at tuxdriver.com>; Luca Boccassi
> > <bluca at debian.org>; Kevin Traynor <ktraynor at redhat.com>; Yigit, Ferruh <ferruh.yigit at intel.com>
> > Subject: Re: [dpdk-dev] [PATCH] cryptodev: version rte_cryptodev_info_get function
> >
> >
> >
> > On 17/04/2020 11:17, Thomas Monjalon wrote:
> > > 17/04/2020 11:42, Ray Kinsella:
> > >> On 17/04/2020 10:31, Bruce Richardson wrote:
> > >>> On Fri, Apr 17, 2020 at 08:24:30AM +0100, Ray Kinsella wrote:
> > >>>> On 16/04/2020 11:01, Thomas Monjalon wrote:
> > >>>>> 16/04/2020 11:51, Bruce Richardson:
> > >>>>>> On Wed, Apr 15, 2020 at 06:24:19PM +0100, Trahe, Fiona wrote:
> > >>>>>>> 5a. If in 20.05 we add a version of a fn which breaks ABI 20.0, what should the name of the
> > original function be? fn_v20, or fn_v20.0
> > >>>>>>
> > >>>>>> In technical terms it really doesn't matter, it's just a name that will be
> > >>>>>> looked up in a table. I don't think we strictly enforce the naming, so
> > >>>>>> whatever is clearest is best. I'd suggest the former.
> > >>>>>
> > >>>>> Each release can have a new ABI.
> > >>>>
> > >>>> How many ABI's do we want to support?
> > >>>>
> > >>> It's not how many we want to support, but for me it's a matter of how many
> > >>> do we need to support. If an API is part of the stable set, it can't just
> > >>> drop to being experimental for one or two releases - it's always stable
> > >>> until deprecated. We also shouldn't have a situation where release 20.08 is
> > >>> ABI compatible with 19.11 but not 20.02 and 20.05.
> > >>
> > >> True. Let me say it differently.
> > >>
> > >> Our only commitment is to support v20 - 19.11
> > >> However you are correct, if something gets committed as v21 in 20.02, in practise should also be
> > there in 20.05+ also.
> > >> Because if it is committed as v21 and not as experimental, it should not be changing once
> > committed.
> > >>
> > >> In answering Thomas,
> > >> I was more commenting on the proliferation of ABI numbers & symbols we need to track in the
> > build.
> > >> With v20, v21 & Experimental we need to keep track of 3.
> > >> If we start allowing quarterly builds to have managed ABI's, it will get confusing.
> > >
> > > I don't remember why we are using intermediate ABI versions
> > > between v20 and v21.
> > > If we can use v21 for new ABI and make sure compatibility is maintained
> > > between all versions from 19.11 to 20.08, I'm fine.
> [Fiona] Here's a hypothetical case, but it illustrates why I don't think there
> should be an expectation to maintain ABI compatibility here.
> Example: in 20.05 add a new info_get_v21() which includes ChaChaPoly.
> In 20.08 add another new algorithm. info_get_v21() return now includes this.
> info_get_v21() will become stable in 20.11 and compatibility must be maintained from then on.
> In the meantime, the fn is not experimental - that wouldn't be appropriate as it was a stable API.
> But an app either wants stability and so should build against 19.11, or if prepared to move up to
> one non-stable-ABI quarterly release should be willing to rebuild for the next non-stable-ABI quarterly
> release.
> I think it's an unnecessary burden to require ABI compatibility across quarterly releases.
> And if required could end up with the version tracking hassle Ray referred to above with fn versions
> of 20.0.1, 20.0.2, 20.0.3, v21, and potentially several versions of same fn.
>