[dpdk-dev] [PATCH v2 3/6] lib/cryptodev: add asymmetric crypto capability in cryptodev
Trahe, Fiona
fiona.trahe at intel.com
Tue May 8 17:00:00 CEST 2018
Hi Shally,
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma at caviumnetworks.com]
> Sent: Thursday, April 5, 2018 12:25 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>
> Cc: Doherty, Declan <declan.doherty at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>;
> pathreya at caviumnetworks.com; ssahu at caviumnetworks.com; agupta at caviumnetworks.com;
> dev at dpdk.org; Sunila Sahu <sunila.sahu at caviumnetworks.com>; Ashish Gupta
> <ashish.gupta at 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.verma at caviumnetworks.com>
> Signed-off-by: Sunila Sahu <sunila.sahu at caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta at 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 ///
More information about the dev
mailing list