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

Ray Kinsella mdr at ashroe.eu
Fri Apr 17 18:01:19 CEST 2020



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

Yes, and the v20 version gets removed in 20.11.

> In the meantime, the fn is not experimental - that wouldn't be appropriate as it was a stable API.

Well it could be ... these are just labels after all.
So it entirely possible and permitted to have a info_get at DPDK_20.0 and info_get at EXPERIMENTAL simultaneously. 

In fact, if it is your expectation that new version will change in successively quarterly releases.
That suggests it should be experimental. 

There in a gap here, we appear to be missing the required MACROS to support a v20.0 + EXPERIMENTAL simultaneously.

As I remember this api was particularly sensitive to size of an enumeration?
Has that been resolved to make the api less brittle?

> 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.

I generally agree with this point.
Our only cast iron solid commitment is compatibility with 19.11.

That said, once any API has dropped the EXPERIMENTAL label, it shouldn't be changing. 
All things being equal quarterly releases should be compatible with each other, as v21 APIs should not be changing. 

> 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.
> 
> 


More information about the dev mailing list