Hi Arek,
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Wednesday, March 20, 2019 6:47 PM
> To: dev@dpdk.org; Trahe, Fiona <fiona.tr...@intel.com>; Doherty, Declan
> <declan.dohe...@intel.com>;
> De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; akhil.go...@nxp.com;
> ravi1.ku...@amd.com;
> t...@semihalf.com; lir...@marvell.com; wa...@marvell.com
> Subject: [RFC] cryptodev/sym: GCM IV len != 12 byte case
>
> Hi all,
>
> There is a proposition to amend a bit API due to the following lines:
>
> * - For GCM mode, this is either 12 (for 96-bit IVs)
> * or 16, in which case data points to J0.
> ...
> } iv; /**< Initialisation vector parameters */
>
>
> Problem arise when driver cannot support J0 input, right now we know that
> OPENSSL PMD works with IV
> instead of J0 when iv_len != 12.
> So it may be that we have to somehow support both. There are two options, and
> I am very curious about
> community opinion.
>
> 1) Add a flag to aead_xform.iv to supports IV or J0 like this:
> uint8_t IV_used;
> And this could be reflected in capabilities. Of course for 96bits IV this
> field would not be used, so it would
> had to be set only for iv.length != 12
> 2) Change API comments to something like:
> * - For GCM mode, this is either 12 (for 96-bit IVs),
> * - for IV length different than 96 bits it is or J0 or IV,
> * - refer to specific driver rst or capabilities which one
> * - is supported, etc. (J0 by definition is of 16 bytes len)
>
> I cc'ing maintainers of drivers that support iv_len != 12 bytes.
> Cannot check how it works as I have no hw.
>
> Regards,
> Arek
[Fiona] Pablo suggested a simpler approach. Same functional change in API -
i.e. support input in both J0 and IV formats, but different implementation, no
need for new flags in session or capabilities. Proposal is to use special value
0 to indicate J0 format, in both capabilities and xform, i.e.
appl passes in rte_crypto_cipher_xform.iv.length = 0
=> J0 format, already known to be 16bytes, so no need for explicit length info
appl passes in iv.length > 0
=> IV, so PMD must derive J0. (current API, no change here)
Capability example1: PMD can accept a 16-byte J0 OR a 12 byte IV
.iv_size = {
.min = 0,
.max = 12,
.increment = 12
}
Capability example2: PMD can accept IV of length 12 and 16, but not J0.
.iv_size = {
.min = 12,
.max = 16,
.increment = 4
}
Capability example3: PMD can accept IV of length between 8 and 128, but not J0.
.iv_size = {
.min = 8,
.max = 128,
.increment = 1
}
Capability example4: PMD can accept IV of length between 1 and 128, and also
J0.
.iv_size = {
.min = 0,
.max = 128,
.increment = 1
}
What do you think?
