[v2,1/9] cryptodev: add feature flag for non-byte aligned data

Message ID 20200509231217.8219-2-akhil.goyal@nxp.com (mailing list archive)
State Accepted, archived
Delegated to: akhil goyal
Headers
Series test/crypto: code cleanup |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-nxp-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-testing fail Testing issues

Commit Message

Akhil Goyal May 9, 2020, 11:12 p.m. UTC
  Some wireless algos like SNOW, ZUC may support input
data in bits which are not byte aligned. However, not
all PMDs can support this requirement. Hence added a
new feature flag RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
to identify which all PMDs can support non-byte aligned
data.

Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
 doc/guides/cryptodevs/features/default.ini | 1 +
 doc/guides/cryptodevs/features/kasumi.ini  | 1 +
 doc/guides/cryptodevs/features/snow3g.ini  | 1 +
 doc/guides/cryptodevs/features/zuc.ini     | 1 +
 drivers/crypto/kasumi/rte_kasumi_pmd.c     | 1 +
 drivers/crypto/snow3g/rte_snow3g_pmd.c     | 1 +
 drivers/crypto/zuc/rte_zuc_pmd.c           | 1 +
 lib/librte_cryptodev/rte_cryptodev.c       | 2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 2 ++
 9 files changed, 11 insertions(+)
  

Comments

Dybkowski, AdamX May 11, 2020, 9:29 a.m. UTC | #1
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Sunday, 10 May, 2020 01:12
> To: dev@dpdk.org
> Cc: Ruifeng.Wang@arm.com; Doherty, Declan <declan.doherty@intel.com>;
> asomalap@amd.com; anoobj@marvell.com; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; G.Singh@nxp.com;
> hemant.agrawal@nxp.com; jianjay.zhou@huawei.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>; Dybkowski, AdamX
> <adamx.dybkowski@intel.com>; apeksha.gupta@nxp.com; Akhil Goyal
> <akhil.goyal@nxp.com>
> Subject: [PATCH v2 1/9] cryptodev: add feature flag for non-byte aligned data
> 
> Some wireless algos like SNOW, ZUC may support input data in bits which are
> not byte aligned. However, not all PMDs can support this requirement.
> Hence added a new feature flag
> RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
> to identify which all PMDs can support non-byte aligned data.
> 
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> ---

Series acked-by: Adam Dybkowski <adamx.dybkowski@intel.com>
  
De Lara Guarch, Pablo May 11, 2020, 9:54 a.m. UTC | #2
Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Sunday, May 10, 2020 12:12 AM
> To: dev@dpdk.org
> Cc: Ruifeng.Wang@arm.com; Doherty, Declan <declan.doherty@intel.com>;
> asomalap@amd.com; anoobj@marvell.com; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; G.Singh@nxp.com;
> hemant.agrawal@nxp.com; jianjay.zhou@huawei.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Dybkowski, AdamX
> <adamx.dybkowski@intel.com>; apeksha.gupta@nxp.com; Akhil Goyal
> <akhil.goyal@nxp.com>
> Subject: [PATCH v2 1/9] cryptodev: add feature flag for non-byte aligned data
> 
> Some wireless algos like SNOW, ZUC may support input data in bits which are
> not byte aligned. However, not all PMDs can support this requirement. Hence
> added a new feature flag RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
> to identify which all PMDs can support non-byte aligned data.
> 
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>

On these PMDs, some of these algorithms do not support non byte aligned data.
For instance, for ZUC, the cipher algorithm doesn't support length in bits,
but the authentication algorithm does.
All test pass because in the tests we are doing encryption in bytes and then we mask off
the bits not used.
Wonder if we need two different flags for this, one for cipher and another one for authentication.
Maybe again this is not enough, since we should have a flag per algorithm... and starting with this flag is a step forward.
What do you think?

Thanks for looking into this!
Pablo
  
Akhil Goyal May 11, 2020, 10:05 a.m. UTC | #3
Hi Pablo,
> 
> Hi Akhil,
> 
> >
> > Some wireless algos like SNOW, ZUC may support input data in bits which are
> > not byte aligned. However, not all PMDs can support this requirement. Hence
> > added a new feature flag RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
> > to identify which all PMDs can support non-byte aligned data.
> >
> > Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> 
> On these PMDs, some of these algorithms do not support non byte aligned data.
> For instance, for ZUC, the cipher algorithm doesn't support length in bits,
> but the authentication algorithm does.
> All test pass because in the tests we are doing encryption in bytes and then we
> mask off
> the bits not used.
> Wonder if we need two different flags for this, one for cipher and another one
> for authentication.
> Maybe again this is not enough, since we should have a flag per algorithm... and
> starting with this flag is a step forward.
> What do you think?
IMO, supporting non-byte-aligned data is a feature as a whole, but we should not have
Per algo basis. It will be better if we come up with something in the capability as we do
For validating the key sizes etc.
We should only have a single flag in feature flag list. Or none if we have a solution which
Is generic in capability.

What do you say?

However for now I am applying this series as this is the solution that we have right now.
We can fix the ZUC issue in probably next release cycle.

Regards,
Akhil
  
Akhil Goyal May 11, 2020, 10:10 a.m. UTC | #4
> > Some wireless algos like SNOW, ZUC may support input data in bits which are
> > not byte aligned. However, not all PMDs can support this requirement.
> > Hence added a new feature flag
> > RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
> > to identify which all PMDs can support non-byte aligned data.
> >
> > Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> > ---
> 
> Series acked-by: Adam Dybkowski <adamx.dybkowski@intel.com>

There are a lot of other stuff which can be cleaned/optimized. I request all the PMD owners to step up
And send the patches.

Applied to dpdk-next-crypto

Thanks.
  
De Lara Guarch, Pablo May 11, 2020, 2:40 p.m. UTC | #5
Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Monday, May 11, 2020 11:05 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; dev@dpdk.org
> Cc: Ruifeng.Wang@arm.com; Doherty, Declan <declan.doherty@intel.com>;
> asomalap@amd.com; anoobj@marvell.com; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; Gagandeep Singh
> <G.Singh@nxp.com>; Hemant Agrawal <hemant.agrawal@nxp.com>;
> jianjay.zhou@huawei.com; Dybkowski, AdamX <adamx.dybkowski@intel.com>;
> Apeksha Gupta <apeksha.gupta@nxp.com>
> Subject: RE: [PATCH v2 1/9] cryptodev: add feature flag for non-byte aligned
> data
> 
> Hi Pablo,
> >
> > Hi Akhil,
> >
> > >
> > > Some wireless algos like SNOW, ZUC may support input data in bits
> > > which are not byte aligned. However, not all PMDs can support this
> > > requirement. Hence added a new feature flag
> > > RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
> > > to identify which all PMDs can support non-byte aligned data.
> > >
> > > Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> >
> > On these PMDs, some of these algorithms do not support non byte aligned
> data.
> > For instance, for ZUC, the cipher algorithm doesn't support length in
> > bits, but the authentication algorithm does.
> > All test pass because in the tests we are doing encryption in bytes
> > and then we mask off the bits not used.
> > Wonder if we need two different flags for this, one for cipher and
> > another one for authentication.
> > Maybe again this is not enough, since we should have a flag per
> > algorithm... and starting with this flag is a step forward.
> > What do you think?
> IMO, supporting non-byte-aligned data is a feature as a whole, but we should
> not have Per algo basis. It will be better if we come up with something in the
> capability as we do For validating the key sizes etc.

So in this case, it would be something per algo basis.

> We should only have a single flag in feature flag list. Or none if we have a
> solution which Is generic in capability.
> 
> What do you say?
> 
> However for now I am applying this series as this is the solution that we have
> right now.
> We can fix the ZUC issue in probably next release cycle.
> 

Agree to leave this for later releases, fixes the problem for now.

> Regards,
> Akhil
> 
>
  

Patch

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 118479db5..fb1ddca71 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -29,6 +29,7 @@  Digest encrypted       =
 Asymmetric sessionless =
 CPU crypto             =
 Symmetric sessionless  =
+Non-Byte aligned data  =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/features/kasumi.ini b/doc/guides/cryptodevs/features/kasumi.ini
index 99ded0401..8380a5765 100644
--- a/doc/guides/cryptodevs/features/kasumi.ini
+++ b/doc/guides/cryptodevs/features/kasumi.ini
@@ -7,6 +7,7 @@ 
 Symmetric crypto       = Y
 Sym operation chaining = Y
 Symmetric sessionless  = Y
+Non-Byte aligned data  = Y
 
 ;
 ; Supported crypto algorithms of the 'kasumi' crypto driver.
diff --git a/doc/guides/cryptodevs/features/snow3g.ini b/doc/guides/cryptodevs/features/snow3g.ini
index 8b971cc1d..b2caefe3a 100644
--- a/doc/guides/cryptodevs/features/snow3g.ini
+++ b/doc/guides/cryptodevs/features/snow3g.ini
@@ -7,6 +7,7 @@ 
 Symmetric crypto       = Y
 Sym operation chaining = Y
 Symmetric sessionless  = Y
+Non-Byte aligned data  = Y
 
 ;
 ; Supported crypto algorithms of the 'snow3g' crypto driver.
diff --git a/doc/guides/cryptodevs/features/zuc.ini b/doc/guides/cryptodevs/features/zuc.ini
index f7bff4291..21d074f9b 100644
--- a/doc/guides/cryptodevs/features/zuc.ini
+++ b/doc/guides/cryptodevs/features/zuc.ini
@@ -7,6 +7,7 @@ 
 Symmetric crypto       = Y
 Sym operation chaining = Y
 Symmetric sessionless  = Y
+Non-Byte aligned data  = Y
 
 ;
 ; Supported crypto algorithms of the 'zuc' crypto driver.
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index a20921249..73077e3d9 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -551,6 +551,7 @@  cryptodev_kasumi_create(const char *name,
 
 	dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
 			RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+			RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA |
 			RTE_CRYPTODEV_FF_SYM_SESSIONLESS;
 
 	mgr = alloc_mb_mgr(0);
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index 8e82dde55..c939064d5 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -563,6 +563,7 @@  cryptodev_snow3g_create(const char *name,
 
 	dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
 			RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+			RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA |
 			RTE_CRYPTODEV_FF_SYM_SESSIONLESS;
 
 	mgr = alloc_mb_mgr(0);
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 17926b471..459881873 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -470,6 +470,7 @@  cryptodev_zuc_create(const char *name,
 
 	dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
 			RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+			RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA |
 			RTE_CRYPTODEV_FF_SYM_SESSIONLESS;
 
 	mb_mgr = alloc_mb_mgr(0);
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 7693eb69c..f30e3cbff 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -500,6 +500,8 @@  rte_cryptodev_get_feature_name(uint64_t flag)
 		return "ASYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_SYM_SESSIONLESS:
 		return "SYM_SESSIONLESS";
+	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
+		return "NON_BYTE_ALIGNED_DATA";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 3dbb5ceb2..257840ea4 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -456,6 +456,8 @@  rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support symmetric cpu-crypto processing */
 #define RTE_CRYPTODEV_FF_SYM_SESSIONLESS		(1ULL << 22)
 /**< Support symmetric session-less operations */
+#define RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA		(1ULL << 23)
+/**< Support operations on data which is not byte aligned */
 
 
 /**