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

[Ray Kinsella <mdr@ashroe.eu>]

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. 

> 
>>> The same function can have a different version in 20.02, 20.05 and 20.08.
>>> If you name it fn_v20 in 20.05, what will be the name for the new version
>>> in 20.08? I suggest using the release number when versioning a function.
>>>
>>
>> ok - so this is exactly _not_ what we wanted at the outset.
>>
>> We committed to support a single ABI, that is the 19.11 (v20) ABI until the 20.11 (v21) ABI.
>> We do _not_ support ABI stability in quarterly releases, as the support overhead would balloon overtime. 
>>
>> Really why would we do this - who would benefit?
>>
>> Do we envisage a situation that someone who built against the say 20.02 shared libraries.
>> would expect their binaries to port to 20.05 without a rebuild?
>>
> I would have expected that, yes, as all have the v20 ABI.
> Maybe I need to change my expectations, though.

You are correct.
However I guess, I would still see them as slightly different levels of commitment.

> 
> /Bruce
> 
>> It would also defeat the purpose of EXPERIMENTAL, if the community where willing to support any permutation of an API.
>> Why would ever bother to use experimental?
>>
>> I have a bit more checking to do, but IMHO the following we should fix the following commits such that APIs are either EXPERIMENTAL or staged for v21. 
>>
>> root@ashroe.eu:/build/dpdk# find . -name *.map | xargs grep 20.0.1
>> ./lib/librte_meter/rte_meter_version.map:DPDK_20.0.1 {
>> ./drivers/vdpa/mlx5/rte_pmd_mlx5_vdpa_version.map:DPDK_20.0.1 {
>> ./drivers/net/ionic/rte_pmd_ionic_version.map:DPDK_20.0.1 {
>> ./drivers/common/octeontx2/rte_common_octeontx2_version.map:DPDK_20.0.1 {
>> ./drivers/common/mlx5/rte_common_mlx5_version.map:DPDK_20.0.1 {
>> ./drivers/raw/octeontx2_ep/rte_rawdev_octeontx2_ep_version.map:DPDK_20.0.1 {
>>
>> Thanks, 
>>
>> Ray K
>>
>>