> >
> >
> > >
> > > Clarify constraints on fields specified in bits for wireless
> > > algorithms in digest-encrypted case.
> > >
> > > v2 changes:
> > > - added note on each of the affected parameter fields
> > >
> > > Signed-off-by: Fiona Trahe <fiona.tr...@intel.com>
> > > ---
> > > lib/librte_cryptodev/rte_crypto_sym.h | 23 +++++++++++++++++++----
> > > 1 files changed, 19 insertions(+), 4 deletions(-)
> > >
> > //snip//
> >
> > > @@ -703,6 +711,13 @@ struct rte_crypto_sym_op {
> > > * auth.data.length and is typically
> > > * equal to auth.data.offset +
> > > * auth.data.length + digest_length.
> > > + * - for wireless algorithms, i.e.
> > > + * SNOW 3G, KASUMI and ZUC, as the
> > > + * cipher.data.length,
> > > + * cipher.data.offset,
> > > + * auth.data.length and
> > > + * auth.data.offset are in bits, they
> > > + * must be 8-bit multiples.
> >
> > Why do you need this change? This is redundant information.
> [Fiona] I think it's useful that it's under the digest-encrypted case notes.
> So ok as is and is good to have info in both places people may look.
> However if we want to avoid duplication, then I'd prefer to keep here and add
> a
> note
> under the specific params to direct to check here. Like:
> *
> and ZUC @
> RTE_CRYPTO_CIPHER_ZUC_EEA3,
> - * this field should be in bits.
> + * this field should be in bits. See
> also
> + * notes about digest-encrypted case.
> */
OK
Acked-by: Akhil Goyal <akhil.go...@nxp.com>
Applied to dpdk-next-crypto
Thanks.
