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

[Ray Kinsella]

Our only commitment is to the stability of the v19.11/v20 ABI, until v21. 

That said, once an ABI migrates from EXPERIMENTAL to v21, it _shouldn't_ be changing.
We don't have a strict commitment to the v21 ABI until v20.11.

However if v21 is changing across quarterlies (outside of additions) ... something else is wrong.

Ray K


On 20/04/2020 17:59, Trahe, Fiona wrote:
> 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.
>>
>