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

[De Lara Guarch, Pablo]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal at nxp.com>
> Sent: Monday, May 11, 2020 11:05 AM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; dev at dpdk.org
> Cc: Ruifeng.Wang at arm.com; Doherty, Declan <declan.doherty at intel.com>;
> asomalap at amd.com; anoobj at marvell.com; Zhang, Roy Fan
> <roy.fan.zhang at intel.com>; Trahe, Fiona <fiona.trahe at intel.com>;
> rnagadheeraj at marvell.com; adwivedi at marvell.com; Gagandeep Singh
> <G.Singh at nxp.com>; Hemant Agrawal <hemant.agrawal at nxp.com>;
> jianjay.zhou at huawei.com; Dybkowski, AdamX <adamx.dybkowski at intel.com>;
> Apeksha Gupta <apeksha.gupta at 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 at nxp.com>
> > > Acked-by: Fiona Trahe <fiona.trahe at 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
> 
>