Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks
From: Thomas Monjalon <hidden>
Date: 2020-03-16 13:09:19
16/03/2020 13:57, Trahe, Fiona:
From: Kusztal, ArkadiuszX <redacted>quoted
quoted
quoted
quoted
The patch we're working on will provide two versions of rte_cryptodev_info_get(), both call the same PMD function from thedev_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 fromthe 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 trimmedlist. 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.[Fiona] Quick recap: To avoid breaking ABI, we must return a set of capabilities with/without ChaChaPoly depending on the appl version. To resolve this, within the rte_cryptodev layer, we propose to inspect the capabilities returned by PMD and strip ChaCha if it exists. In that case memory for the new trimmed capabilities array has to be malloced by the lib.
What happens if the capability is removed from the original capabilities input?
All good, except how to handle a malloc fail is yet another API breakage as rte_cryptodev_get_info() returns void. We propose to return an empty capability list, i.e. a list with only the END element (which can be done without malloc) in this corner case of a corner case. Anyone see any issue with this?
How can we use the feature if it is not advertised in capabilities?