[dpdk-dev] [PATCH v2 3/6] lib/cryptodev: add asymmetric crypto capability in cryptodev

[Trahe, Fiona]

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 ///