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

[Trahe, Fiona]

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.