Hi,

Two comments from me,

quoted

quoted

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.

quoted

quoted

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. 

[Arek] The problem with this solution is that we need to allocate memory.
So the question is how to handle unlikely case of malloc error when we operate inside void function rte_cryptodev_info_get?
And even if we would pass somehow error condition to the caller then what to do is another question.

quoted

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[]

Should we print user some information

quoted

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.

quoted

quoted

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.

[Arek] - Yes, it is error path but on the other hand we explicitly specify what value we will return when calling
rte_cryptodev_sym_session_init so caller may expect EINVAL when wrong algorithm value selected (usually it probably will be ENOTSUP).
In this case when setting 3 (LIST_END) on 19.11 app and linking against 20.02 (assuming with Chacha) shared build, caller would get success on return and fully set chacha session,
which will probably result in undefined behavior.
So shouldn't this function be versioned as well then?

Regards,
Arek