Re: [dpdk-dev] [PATCH 2/8] crypto/octeontx: add RSA and modexp asym capabilities

[Anoob Joseph <anoobj@marvell.com>]

Hi Akhil,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, October 1, 2019 6:08 PM
> To: Anoob Joseph <anoobj@marvell.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>; Jerin Jacob
> Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Fiona Trahe <fiona.trahe@intel.com>; Shally Verma
> <shallyv@marvell.com>; Sunila Sahu <ssahu@marvell.com>; dev@dpdk.org
> Subject: RE: [PATCH 2/8] crypto/octeontx: add RSA and modexp asym
> capabilities
> 
> Hi Anoob,
> 
> >  const struct rte_cryptodev_capabilities *
> > -otx_get_capabilities(void)
> > +otx_get_capabilities(uint64_t flags)
> >  {
> > -	return otx_capabilities;
> > +	if (flags & RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO)
> > +		return otx_asym_capabilities;
> > +	else
> > +		return otx_sym_capabilities;
> > +
> >  }
> 
> I believe this will give Asym capabilities always. As the feature flag
> RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO will always be set, as the flags are
> set in init.
> 
> It will never go in else.

[Anoob] The flags is set based on the type of underlying device. The crypto module on OCTEONTX exposes two kinds of VFs. One which does only symmetric and one which does only asymmetric. Both are never supported together for a VF, and hence the if...else.

From the first patch, crypto/octeontx: add device type mailbox routine

	switch (cptvf->vftype) {
	case OTX_CPT_VF_TYPE_AE:
		/* Set asymmetric cpt feature flags */
		c_dev->feature_flags = RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO |
				RTE_CRYPTODEV_FF_HW_ACCELERATED;
		break;
	case OTX_CPT_VF_TYPE_SE:
		/* Set symmetric cpt feature flags */
		c_dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
				RTE_CRYPTODEV_FF_HW_ACCELERATED |
				RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
				RTE_CRYPTODEV_FF_IN_PLACE_SGL |
				RTE_CRYPTODEV_FF_OOP_SGL_IN_LB_OUT |
				RTE_CRYPTODEV_FF_OOP_SGL_IN_SGL_OUT;
		break;

Hope this clarifies. 

> 
> > diff --git a/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > b/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > index fc62821..439b50e 100644
> > --- a/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > +++ b/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > @@ -8,10 +8,9 @@
> >  #include <rte_cryptodev.h>
> >
> >  /*
> > - * Get capabilities list for the device
> > - *
> > + * Get capabilities list for the device, based on device type
> >   */
> >  const struct rte_cryptodev_capabilities *
> > -otx_get_capabilities(void);
> > +otx_get_capabilities(uint64_t flags);
> >
> >  #endif /* _OTX_CRYPTODEV_CAPABILITIES_H_ */ diff --git
> > a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > index 88efed3..b59a001 100644
> > --- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > +++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > @@ -105,7 +105,7 @@ otx_cpt_dev_info_get(struct rte_cryptodev *dev,
> > struct rte_cryptodev_info *info)
> >  	if (info != NULL) {
> >  		info->max_nb_queue_pairs = CPT_NUM_QS_PER_VF;
> >  		info->feature_flags = dev->feature_flags;
> > -		info->capabilities = otx_get_capabilities();
> > +		info->capabilities = otx_get_capabilities(info->feature_flags);
> >  		info->sym.max_nb_sessions = 0;
> >  		info->driver_id = otx_cryptodev_driver_id;
> >  		info->min_mbuf_headroom_req =
> > OTX_CPT_MIN_HEADROOM_REQ;
> > @@ -635,7 +635,8 @@ otx_cpt_dev_create(struct rte_cryptodev *c_dev)
> >  	case OTX_CPT_VF_TYPE_AE:
> >  		/* Set asymmetric cpt feature flags */
> >  		c_dev->feature_flags =
> > RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO |
> > -				RTE_CRYPTODEV_FF_HW_ACCELERATED;
> > +				RTE_CRYPTODEV_FF_HW_ACCELERATED |
> > +				RTE_CRYPTODEV_FF_RSA_PRIV_OP_KEY_QT;
> >  		break;
> >  	case OTX_CPT_VF_TYPE_SE:
> >  		/* Set symmetric cpt feature flags */
> > --
> > 2.7.4