Hi Akhil, > -----Original Message----- > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > Sent: Tuesday, October 22, 2019 12:49 PM > To: Trahe, Fiona <fiona.tr...@intel.com>; dev@dpdk.org > Cc: Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; Dybkowski, AdamX > <adamx.dybkow...@intel.com> > Subject: RE: [PATCH] cryptodev: clarify wireless inputs in digest-encrypted > cases > > Hi Fiona, > > > > > Clarify constraints on fields specified in bits for wireless > > algorithms in digest-encrypted case. > > > > Signed-off-by: Fiona Trahe <fiona.tr...@intel.com> > > --- > > lib/librte_cryptodev/rte_crypto_sym.h | 7 +++++++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/lib/librte_cryptodev/rte_crypto_sym.h > > b/lib/librte_cryptodev/rte_crypto_sym.h > > index bc8da24..0204d37 100644 > > --- a/lib/librte_cryptodev/rte_crypto_sym.h > > +++ b/lib/librte_cryptodev/rte_crypto_sym.h > > @@ -703,6 +703,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. > > What is the meaning of 'they' here? > cipher.data.length, cipher.data.offset, auth.data.length and auth.data.offset > are in bits > and may or may not be multiple of 8bits. This is documented in their comments. > [Fiona] This added note is an extra bullet under the explanation for Digest-encrypted cases. In these cases only those fields listed MUST be 8-bit multiples. Can you suggest a change that would make that clearer?
> > > * > > * Note, that for security reasons, it > > * is PMDs' responsibility to not > > -- > > 1.7.0.7
