[dpdk-dev] [PATCH] cryptodev: clarify wireless inputs in digest-encrypted cases

Akhil Goyal akhil.goyal at nxp.com
Tue Oct 22 13:48:46 CEST 2019


Hi Fiona,

> 
> Clarify constraints on fields specified in bits for wireless
> algorithms in digest-encrypted case.
> 
> Signed-off-by: Fiona Trahe <fiona.trahe at 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.


>  					 *
>  					 * Note, that for security reasons, it
>  					 * is PMDs' responsibility to not
> --
> 1.7.0.7



More information about the dev mailing list