16/03/2020 13:57, Trahe, Fiona: > From: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com> > > > > > 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. > > > > > 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. > > [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?
