> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Tuesday, March 17, 2020 4:10 PM
> To: Trahe, Fiona <fiona.tr...@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusz...@intel.com>
> Cc: David Marchand <david.march...@redhat.com>;
> nhor...@tuxdriver.com; bl...@debian.org; ktray...@redhat.com; Ray
> Kinsella <m...@ashroe.eu>; dev@dpdk.org; Akhil Goyal
> <akhil.go...@nxp.com>; Yigit, Ferruh <ferruh.yi...@intel.com>; Ananyev,
> Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org; Anoob Joseph
> <ano...@marvell.com>; Richardson, Bruce <bruce.richard...@intel.com>;
> Mcnamara, John <john.mcnam...@intel.com>; do...@seketeli.net; Andrew
> Rybchenko <arybche...@solarflare.com>; acon...@redhat.com; Trahe,
> Fiona <fiona.tr...@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks
>
> 17/03/2020 14:27, Kusztal, ArkadiuszX:
> > Hi Thomas,
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <tho...@monjalon.net>
> > > Sent: Monday, March 16, 2020 2:09 PM
> > > To: Trahe, Fiona <fiona.tr...@intel.com>
> > > Cc: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; David
> > > Marchand <david.march...@redhat.com>; nhor...@tuxdriver.com;
> > > bl...@debian.org; ktray...@redhat.com; Ray Kinsella
> <m...@ashroe.eu>;
> > > dev@dpdk.org; Akhil Goyal <akhil.go...@nxp.com>; Yigit, Ferruh
> > > <ferruh.yi...@intel.com>; Ananyev, Konstantin
> > > <konstantin.anan...@intel.com>; dev@dpdk.org; Anoob Joseph
> > > <ano...@marvell.com>; Richardson, Bruce
> > > <bruce.richard...@intel.com>; Mcnamara, John
> > > <john.mcnam...@intel.com>; do...@seketeli.net; Andrew Rybchenko
> > > <arybche...@solarflare.com>; acon...@redhat.com; Trahe, Fiona
> > > <fiona.tr...@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v2 4/4] add ABI checks
> > >
> > > 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?
> > What Fiona meant is that empty capability would indicate error condition in
> this case. That's why she asked if you ok with this API breakage.
>
> Sorry I'm lost.
> Please could you show what would be the usage?
>
So this case looks more or less like that:
There are two versions of `rte_cryptodev_info_get`
rte_cryptodev_info_get_v20 (versioned)
rte_cryptodev_info_get_v2005 (new default symbol)
Default version works normally as it will be called only by app build with
20.05 version.
When prior to 20.05 app calls `rte_cryptodev_info_get` version v20 is called.
This function will remove Chacha Poly from capabilities, but to achieve this we
need to get some memory to store `new` set of capabilities per device (without
Chacha). So:
new_capability[dev_id] = malloc( (num_of_capabilies - 1 (chacha)) *
sizeof(struct rte_cryptodev_capabilities))
The small problem is how to handle malloc error:
If (new_capability[dev_id] == NULL) {
/* What to do now as rte_cryptodev_info_get is void function, and API
does not say anything about error condition */
/*So Fiona suggestion above is to inform user of an error by doing this: */
dev_info->capabilities = cryptodev_undefined_capabilities;
/* Where
static const struct rte_cryptodev_capabilities
cryptodev_undefined_capabilities[] = {
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
}; */
}
Sizeof rte_cryptodev_capabilities is 38 bytes, padded to 40. So properly
constructed capabilities can take at most 1920 bytes. No system should ever
fail doing that though iam not an expert. Other option could probably be to
preallocate this memory. This is how I understand that.
Another question is can something like that be done if API comments of
`rte_cryptodev_info_get` function does not say anything about any potential
error?
Regards,
Arek
