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.
> *
> * Note, that for security reasons, it
> * is PMDs' responsibility to not
> --
> 1.7.0.7
