-----Original Message-----
From: Thomas Monjalon <redacted>
Sent: Tuesday, February 4, 2020 4:00 PM
To: Trahe, Fiona <redacted>
Cc: David Marchand <redacted>; nhorman@tuxdriver.com; bluca@debian.org;
ktraynor@redhat.com; Ray Kinsella [off-list ref]; dev@dpdk.org; Akhil Goyal
[off-list ref]; Yigit, Ferruh [off-list ref]; Ananyev, Konstantin
[off-list ref]; dev@dpdk.org; Anoob Joseph [off-list ref]; Kusztal,
ArkadiuszX [off-list ref]; Richardson, Bruce [off-list ref];
Mcnamara, John [off-list ref]; dodji@seketeli.net; Andrew Rybchenko
[off-list ref]; aconole@redhat.com
Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks

04/02/2020 16:52, Trahe, Fiona:

quoted

quoted

We are working on a patch, when it is ready we will send it.
If it's not ready by end of your today, of course, go ahead with (b) and
we will work towards 20.05.

We will not be sending a patch today.
The patch we're working on will provide two versions of rte_cryptodev_info_get(),
both call the same PMD function from the dev_ops info_get fn ptr.
The default version operates s as normal, the 19.11 version searches
through the list returned by the PMD, looking for sym.aead.algo = ChaChaPoly, it needs to strip it from

the list.

quoted

As PMDs just pass a ptr to their capabilities list ( it isn't a linked list, but an array
with an end marker  = RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST) if the API
layer detects Chacha it must allocate some space and store a local copy of the
trimmed list. This must be stored only once per device.

I don't understand what you have to store.
Can't you just set the algo to 0 if it is ChaCha?

[Fiona] it returns a pointer to data in the PMD domain, which the API couldn't and shouldn't overwrite, e.g.
static const struct rte_cryptodev_capabilities qat_gen3_sym_capabilities[]

quoted

This versioning will apply to any PMD which wants to take advantage of the new API between now and

20.11.

quoted

Note, I expect the ABI checker tools will still complain of ABI breakage as the LIST_END value will still

change.

Right, you need to update the ignore list for the tool.

quoted

We are also reviewing all other cryptodev APIs in case there is any other API which needs versioning.

Anyone see any problem with this approach?

The other issue is with all other functions accepting this enum as input.
We should continue returning an error if getting Chacha as input with
19.11 version of these functions.
But I would tend to consider this small ABI breakage can be ignored
as it is in the error path.

[Fiona] The QAT PMD tests for and handles this error. I expect other PMDs do too.