Hi Shally,

> -----Original Message-----
> From: Shally Verma [mailto:shally.ve...@caviumnetworks.com]
> Sent: Thursday, April 5, 2018 12:25 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>
> Cc: Doherty, Declan <declan.dohe...@intel.com>; Trahe, Fiona 
> <fiona.tr...@intel.com>;
> pathr...@caviumnetworks.com; ss...@caviumnetworks.com; 
> agu...@caviumnetworks.com;
> dev@dpdk.org; Sunila Sahu <sunila.s...@caviumnetworks.com>; Ashish Gupta
> <ashish.gu...@caviumnetworks.com>
> Subject: [PATCH v2 3/6] lib/cryptodev: add asymmetric crypto capability in 
> cryptodev
> 
> Extend cryptodev with asymmetric capability APIs and
> definitions.
> 
> Signed-off-by: Shally Verma <shally.ve...@caviumnetworks.com>
> Signed-off-by: Sunila Sahu <sunila.s...@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gu...@caviumnetworks.com>
> 
> ---
/// snip ///
> +int __rte_experimental
> +rte_cryptodev_asym_xfrm_capability_check_modlen(
> +     const struct rte_cryptodev_asymmetric_xfrm_capability *capability,
> +     uint16_t modlen)
> +{
> +     /* handle special case of 0 which mean PMD define no limit defined */
[Fiona] grammar. Maybe "which means PMD doesn't define any limit"

> +     if ((capability->modlen.min != 0) &&
> +             ((modlen < capability->modlen.min) ||
> +             (capability->modlen.increment != 0 &&
> +             (modlen % (capability->modlen.increment)))))
> +             return -1;
> +     if ((capability->modlen.max != 0) &&
> +             ((modlen > capability->modlen.max) ||
> +             (capability->modlen.increment != 0 &&
> +             (modlen % (capability->modlen.increment)))))
> +             return -1;
> +
> +     return 0;
> +}
> +
> 
>  const char *
>  rte_cryptodev_get_feature_name(uint64_t flag)
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h 
> b/lib/librte_cryptodev/rte_cryptodev.h
> index 68d1ae1..deae3d6 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -178,6 +178,37 @@ struct rte_cryptodev_symmetric_capability {
>       };
>  };
> 
> +/**
> + * Asymmetric Xform Crypto Capability
> + *
> + */
> +struct rte_cryptodev_asymmetric_xfrm_capability {
> +     enum rte_crypto_asym_xform_type xform_type;
> +     /**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> +
> +     uint32_t op_types;
> +     /**< bitmask for supported rte_crypto_asym_op_type */
> +
> +     __extension__
> +     union {
> +             struct rte_crypto_param_range modlen;
> +             /**< Range of modulus length supported by modulus based xform.
> +              * Value 0 mean implementation default
> +              */
> +     };
> +};
> +
> +/**
> + * Asymmetric Crypto Capability
> + *
> + */
> +struct rte_cryptodev_asymmetric_capability {
> +     enum rte_crypto_asym_xform_type xform_type;
> +     /**< Transform type: RSA/MODEXP/DH/DSA/MODINV */
> +     struct rte_cryptodev_asymmetric_xfrm_capability xfrm_capa;
> +};
[Fiona] Is it necessary to have xform_type in both above structures?
Seems like duplication. Or would it be better if both are combined into 1 
struct?

> +
> +
>  /** Structure used to capture a capability of a crypto device */
>  struct rte_cryptodev_capabilities {
>       enum rte_crypto_op_type op;
> @@ -187,6 +218,8 @@ struct rte_cryptodev_capabilities {
>       union {
>               struct rte_cryptodev_symmetric_capability sym;
>               /**< Symmetric operation capability parameters */
> +             struct rte_cryptodev_asymmetric_capability asym;
> +             /**< Asymmetric operation capability parameters */
>       };
>  };
/// snip ///

Reply via email to