[v2,1/9] cryptodev: add feature flag for non-byte aligned data
Checks
Commit Message
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
> -----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>
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
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
> > 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.
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
>
>
@@ -29,6 +29,7 @@ Digest encrypted =
Asymmetric sessionless =
CPU crypto =
Symmetric sessionless =
+Non-Byte aligned data =
;
; Supported crypto algorithms of a default crypto driver.
@@ -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.
@@ -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.
@@ -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.
@@ -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);
@@ -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);
@@ -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);
@@ -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;
}
@@ -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 */
/**