diff mbox series

[11/40] cryptodev: remove asym crypto next xform

Message ID 20220520055445.40063-12-arkadiuszx.kusztal@intel.com (mailing list archive)
State Changes Requested
Delegated to: akhil goyal
Headers show
Series cryptodev: rsa, dh, ecdh changes | expand

Checks

Context Check Description
ci/checkpatch success coding style OK

Commit Message

Kusztal, ArkadiuszX May 20, 2022, 5:54 a.m. UTC
- removed asymnetric crypto xform next field.
Rationale behind having chaining in symmetric crypto
was a fact that encryption and authentication are usually
done on the same set of data independent of algorithm.
HW usually will be able to handle it in one PCI call.
In asymmetric there is no such relation between algorithms,
therefore next field would be useless.

Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
 lib/cryptodev/rte_crypto_asym.h | 2 --
 1 file changed, 2 deletions(-)

Comments

Akhil Goyal May 20, 2022, 7:22 a.m. UTC | #1
> - removed asymnetric crypto xform next field.
> Rationale behind having chaining in symmetric crypto
> was a fact that encryption and authentication are usually
> done on the same set of data independent of algorithm.
> HW usually will be able to handle it in one PCI call.
> In asymmetric there is no such relation between algorithms,
> therefore next field would be useless.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---

Squash 12,13,14 patches or else compilation will be broken

>  lib/cryptodev/rte_crypto_asym.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 1652a434a5..b355cbe5fa 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
>   * Structure describing asym xforms.
>   */
>  struct rte_crypto_asym_xform {
> -	struct rte_crypto_asym_xform *next;
> -	/**< Pointer to next xform to set up xform chain.*/
>  	enum rte_crypto_asym_xform_type xform_type;
>  	/**< Asymmetric crypto transform */
> 
> --
> 2.13.6
Akhil Goyal May 24, 2022, 11:12 a.m. UTC | #2
> - removed asymnetric crypto xform next field.
> Rationale behind having chaining in symmetric crypto
> was a fact that encryption and authentication are usually
> done on the same set of data independent of algorithm.
> HW usually will be able to handle it in one PCI call.
> In asymmetric there is no such relation between algorithms,
> therefore next field would be useless.
> 
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>

Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
asymmetric crypto xforms.

> ---
>  lib/cryptodev/rte_crypto_asym.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 1652a434a5..b355cbe5fa 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
>   * Structure describing asym xforms.
>   */
>  struct rte_crypto_asym_xform {
> -	struct rte_crypto_asym_xform *next;
> -	/**< Pointer to next xform to set up xform chain.*/
>  	enum rte_crypto_asym_xform_type xform_type;
>  	/**< Asymmetric crypto transform */
> 
> --
> 2.13.6
Kusztal, ArkadiuszX May 24, 2022, 2:47 p.m. UTC | #3
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, May 24, 2022 1:13 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> > - removed asymnetric crypto xform next field.
> > Rationale behind having chaining in symmetric crypto was a fact that
> > encryption and authentication are usually done on the same set of data
> > independent of algorithm.
> > HW usually will be able to handle it in one PCI call.
> > In asymmetric there is no such relation between algorithms, therefore
> > next field would be useless.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> 
> Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> Not all asymmetric crypto xforms are supported for chaining. Currently
> supported asymmetric crypto chaining is Diffie-Hellman private key generation
> followed by public generation. 
[Arek] And why do chaining when this can be done even with one bit flag.

Also, currently API does not support chaining of
> symmetric and asymmetric crypto xforms.
[Arek] - This is one unlikely scenario to combine symmetric and asymmetric. One I can think of was once proposed DH + DSA integration for random number. But not much else, although we can keep it around for a while.
> 
> > ---
> >  lib/cryptodev/rte_crypto_asym.h | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> >   * Structure describing asym xforms.
> >   */
> >  struct rte_crypto_asym_xform {
> > -	struct rte_crypto_asym_xform *next;
> > -	/**< Pointer to next xform to set up xform chain.*/
> >  	enum rte_crypto_asym_xform_type xform_type;
> >  	/**< Asymmetric crypto transform */
> >
> > --
> > 2.13.6
Akhil Goyal May 25, 2022, 6:06 a.m. UTC | #4
> > > - removed asymnetric crypto xform next field.
> > > Rationale behind having chaining in symmetric crypto was a fact that
> > > encryption and authentication are usually done on the same set of data
> > > independent of algorithm.
> > > HW usually will be able to handle it in one PCI call.
> > > In asymmetric there is no such relation between algorithms, therefore
> > > next field would be useless.
> > >
> > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >
> > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > Not all asymmetric crypto xforms are supported for chaining. Currently
> > supported asymmetric crypto chaining is Diffie-Hellman private key generation
> > followed by public generation.
> [Arek] And why do chaining when this can be done even with one bit flag.
> 
I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob please confirm.

If we are removing it, then documentation should be in sync.

> Also, currently API does not support chaining of
> > symmetric and asymmetric crypto xforms.
> [Arek] - This is one unlikely scenario to combine symmetric and asymmetric. One
> I can think of was once proposed DH + DSA integration for random number. But
> not much else, although we can keep it around for a while.

Yes it is highly unlikely to use this combination.

> >
> > > ---
> > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > >   * Structure describing asym xforms.
> > >   */
> > >  struct rte_crypto_asym_xform {
> > > -	struct rte_crypto_asym_xform *next;
> > > -	/**< Pointer to next xform to set up xform chain.*/
> > >  	enum rte_crypto_asym_xform_type xform_type;
> > >  	/**< Asymmetric crypto transform */
> > >
> > > --
> > > 2.13.6
Kusztal, ArkadiuszX May 25, 2022, 6:36 a.m. UTC | #5
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Wednesday, May 25, 2022 8:06 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org; Kiran
> Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> > > > - removed asymnetric crypto xform next field.
> > > > Rationale behind having chaining in symmetric crypto was a fact
> > > > that encryption and authentication are usually done on the same
> > > > set of data independent of algorithm.
> > > > HW usually will be able to handle it in one PCI call.
> > > > In asymmetric there is no such relation between algorithms,
> > > > therefore next field would be useless.
> > > >
> > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >
> > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > Not all asymmetric crypto xforms are supported for chaining.
> > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > private key generation followed by public generation.
> > [Arek] And why do chaining when this can be done even with one bit flag.
> >
> I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob please
> confirm.
> 
> If we are removing it, then documentation should be in sync.
[Arek] - although, we may keep it for now, I am not dropping it in v2. DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in ecdsa when k.data = NULL.
But I do not see any situation for now it will be  useful, it may be dropped later if not application found.
> 
> > Also, currently API does not support chaining of
> > > symmetric and asymmetric crypto xforms.
> > [Arek] - This is one unlikely scenario to combine symmetric and
> > asymmetric. One I can think of was once proposed DH + DSA integration
> > for random number. But not much else, although we can keep it around for a
> while.
> 
> Yes it is highly unlikely to use this combination.
> 
> > >
> > > > ---
> > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > 100644
> > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > >   * Structure describing asym xforms.
> > > >   */
> > > >  struct rte_crypto_asym_xform {
> > > > -	struct rte_crypto_asym_xform *next;
> > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > >  	/**< Asymmetric crypto transform */
> > > >
> > > > --
> > > > 2.13.6
Anoob Joseph May 25, 2022, 7:05 a.m. UTC | #6
Hi Arek, Akhil,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Wednesday, May 25, 2022 12:06 PM
> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Akhil Goyal <gakhil@marvell.com>
> > Sent: Wednesday, May 25, 2022 8:06 AM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org;
> > Kiran Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > > > > - removed asymnetric crypto xform next field.
> > > > > Rationale behind having chaining in symmetric crypto was a fact
> > > > > that encryption and authentication are usually done on the same
> > > > > set of data independent of algorithm.
> > > > > HW usually will be able to handle it in one PCI call.
> > > > > In asymmetric there is no such relation between algorithms,
> > > > > therefore next field would be useless.
> > > > >
> > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > >
> > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > private key generation followed by public generation.
> > > [Arek] And why do chaining when this can be done even with one bit flag.
> > >
> > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > please confirm.
> >
> > If we are removing it, then documentation should be in sync.
> [Arek] - although, we may keep it for now, I am not dropping it in v2. DH priv +
> pub can be done with priv_key.len = 0 -> similar as 'k' in ecdsa when k.data =
> NULL.
> But I do not see any situation for now it will be  useful, it may be dropped later if
> not application found.
> >
> > > Also, currently API does not support chaining of
> > > > symmetric and asymmetric crypto xforms.
> > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > asymmetric. One I can think of was once proposed DH + DSA
> > > integration for random number. But not much else, although we can
> > > keep it around for a
> > while.
> >
> > Yes it is highly unlikely to use this combination.

[Anoob] We may need this support when we add EdDSA support. That would involve a asymmetric operation after hash is generated (symmetric). 
https://en.wikipedia.org/wiki/EdDSA#Ed25519

And, asymmetric chaining may become useful when we have PMDs capable of doing more operations together (like the case with EdDSA). So my preference would be to retain the 'next' field in asym crypto xform.
 
> >
> > > >
> > > > > ---
> > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > 100644
> > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > >   * Structure describing asym xforms.
> > > > >   */
> > > > >  struct rte_crypto_asym_xform {
> > > > > -	struct rte_crypto_asym_xform *next;
> > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > >  	/**< Asymmetric crypto transform */
> > > > >
> > > > > --
> > > > > 2.13.6
Kusztal, ArkadiuszX May 27, 2022, 6:30 a.m. UTC | #7
Hi Anoob,

Sorry, I don't know how I have missed this email!

> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Wednesday, May 25, 2022 9:06 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Arek, Akhil,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Wednesday, May 25, 2022 12:06 PM
> > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Akhil Goyal <gakhil@marvell.com>
> > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>;
> > > Anoob Joseph <anoobj@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > > > > - removed asymnetric crypto xform next field.
> > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > fact that encryption and authentication are usually done on
> > > > > > the same set of data independent of algorithm.
> > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > In asymmetric there is no such relation between algorithms,
> > > > > > therefore next field would be useless.
> > > > > >
> > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > >
> > > > > Please check documentation "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > Currently supported asymmetric crypto chaining is Diffie-Hellman
> > > > > private key generation followed by public generation.
> > > > [Arek] And why do chaining when this can be done even with one bit flag.
> > > >
> > > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > > please confirm.
> > >
> > > If we are removing it, then documentation should be in sync.
> > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in
> > ecdsa when k.data = NULL.
> > But I do not see any situation for now it will be  useful, it may be
> > dropped later if not application found.
> > >
> > > > Also, currently API does not support chaining of
> > > > > symmetric and asymmetric crypto xforms.
> > > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > > asymmetric. One I can think of was once proposed DH + DSA
> > > > integration for random number. But not much else, although we can
> > > > keep it around for a
> > > while.
> > >
> > > Yes it is highly unlikely to use this combination.
> 
> [Anoob] We may need this support when we add EdDSA support. That would
> involve a asymmetric operation after hash is generated (symmetric).
> https://en.wikipedia.org/wiki/EdDSA#Ed25519
> 
> And, asymmetric chaining may become useful when we have PMDs capable of
> doing more operations together (like the case with EdDSA). So my preference
> would be to retain the 'next' field in asym crypto xform.
[Arek] - that is very good point, however to implement EdDSA as chaining would mean that:
- we need to implement EdDSA internals in DPDK
- and EdDSA (in hash option, where actually picking hash would have sense) is not one hash but multiple hash operation, so we would have to had multiple chaining with operations in between
- and we would have to compute R and S separately.
- If PMD does not support one-pass EdDSA - well this is something that should definitely discuss, but having any crypto internals in DPDK is not probably an option?

> 
> > >
> > > > >
> > > > > > ---
> > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > >  1 file changed, 2 deletions(-)
> > > > > >
> > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > b/lib/cryptodev/rte_crypto_asym.h index 1652a434a5..b355cbe5fa
> > > > > > 100644
> > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > >   * Structure describing asym xforms.
> > > > > >   */
> > > > > >  struct rte_crypto_asym_xform {
> > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > >  	/**< Asymmetric crypto transform */
> > > > > >
> > > > > > --
> > > > > > 2.13.6
Kusztal, ArkadiuszX May 27, 2022, 6:40 a.m. UTC | #8
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Friday, May 27, 2022 8:31 AM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Anoob,
> 
> Sorry, I don't know how I have missed this email!
> 
> > -----Original Message-----
> > From: Anoob Joseph <anoobj@marvell.com>
> > Sent: Wednesday, May 25, 2022 9:06 AM
> > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > Hi Arek, Akhil,
> >
> > Please see inline.
> >
> > Thanks,
> > Anoob
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > <anoobj@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>;
> > > > Anoob Joseph <anoobj@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > > fact that encryption and authentication are usually done on
> > > > > > > the same set of data independent of algorithm.
> > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > In asymmetric there is no such relation between algorithms,
> > > > > > > therefore next field would be useless.
> > > > > > >
> > > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > >
> > > > > > Please check documentation
> "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > Currently supported asymmetric crypto chaining is
> > > > > > Diffie-Hellman private key generation followed by public generation.
> > > > > [Arek] And why do chaining when this can be done even with one bit flag.
> > > > >
> > > > I believe it is OK to remove next. @Kiran Kumar Kokkilagadda/Anoob
> > > > please confirm.
> > > >
> > > > If we are removing it, then documentation should be in sync.
> > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k' in
> > > ecdsa when k.data = NULL.
> > > But I do not see any situation for now it will be  useful, it may be
> > > dropped later if not application found.
> > > >
> > > > > Also, currently API does not support chaining of
> > > > > > symmetric and asymmetric crypto xforms.
> > > > > [Arek] - This is one unlikely scenario to combine symmetric and
> > > > > asymmetric. One I can think of was once proposed DH + DSA
> > > > > integration for random number. But not much else, although we
> > > > > can keep it around for a
> > > > while.
> > > >
> > > > Yes it is highly unlikely to use this combination.
> >
> > [Anoob] We may need this support when we add EdDSA support. That would
> > involve a asymmetric operation after hash is generated (symmetric).
> > https://en.wikipedia.org/wiki/EdDSA#Ed25519
> >
> > And, asymmetric chaining may become useful when we have PMDs capable
> > of doing more operations together (like the case with EdDSA). So my
> > preference would be to retain the 'next' field in asym crypto xform.
> [Arek] - that is very good point, however to implement EdDSA as chaining would
> mean that:
> - we need to implement EdDSA internals in DPDK
> - and EdDSA (in hash option, where actually picking hash would have sense) is
> not one hash but multiple hash operation, so we would have to had multiple
> chaining with operations in between
> - and we would have to compute R and S separately.
> - If PMD does not support one-pass EdDSA - well this is something that should
> definitely discuss, but having any crypto internals in DPDK is not probably an
> option?
[Arek] - but, I have kept 'next' in later changes.
> 
> >
> > > >
> > > > > >
> > > > > > > ---
> > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > >  1 file changed, 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > 100644
> > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > >   * Structure describing asym xforms.
> > > > > > >   */
> > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > >
> > > > > > > --
> > > > > > > 2.13.6
Kusztal, ArkadiuszX May 27, 2022, 6:55 a.m. UTC | #9
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Friday, May 27, 2022 8:40 AM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Friday, May 27, 2022 8:31 AM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> > Hi Anoob,
> >
> > Sorry, I don't know how I have missed this email!
> >
> > > -----Original Message-----
> > > From: Anoob Joseph <anoobj@marvell.com>
> > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > Hi Arek, Akhil,
> > >
> > > Please see inline.
> > >
> > > Thanks,
> > > Anoob
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > <anoobj@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > Rationale behind having chaining in symmetric crypto was a
> > > > > > > > fact that encryption and authentication are usually done
> > > > > > > > on the same set of data independent of algorithm.
> > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > In asymmetric there is no such relation between
> > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > >
> > > > > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > > >
> > > > > > > Please check documentation
> > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > Diffie-Hellman private key generation followed by public generation.
> > > > > > [Arek] And why do chaining when this can be done even with one bit
> flag.
> > > > > >
> > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > Kokkilagadda/Anoob please confirm.
> > > > >
> > > > > If we are removing it, then documentation should be in sync.
> > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > in ecdsa when k.data = NULL.
> > > > But I do not see any situation for now it will be  useful, it may
> > > > be dropped later if not application found.
> > > > >
> > > > > > Also, currently API does not support chaining of
> > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > [Arek] - This is one unlikely scenario to combine symmetric
> > > > > > and asymmetric. One I can think of was once proposed DH + DSA
> > > > > > integration for random number. But not much else, although we
> > > > > > can keep it around for a
> > > > > while.
> > > > >
> > > > > Yes it is highly unlikely to use this combination.
> > >
> > > [Anoob] We may need this support when we add EdDSA support. That
> > > would involve a asymmetric operation after hash is generated (symmetric).
> > > https://en.wikipedia.org/wiki/EdDSA#Ed25519
> > >
> > > And, asymmetric chaining may become useful when we have PMDs capable
> > > of doing more operations together (like the case with EdDSA). So my
> > > preference would be to retain the 'next' field in asym crypto xform.
> > [Arek] - that is very good point, however to implement EdDSA as
> > chaining would mean that:
> > - we need to implement EdDSA internals in DPDK
> > - and EdDSA (in hash option, where actually picking hash would have
> > sense) is not one hash but multiple hash operation, so we would have
> > to had multiple chaining with operations in between
> > - and we would have to compute R and S separately.
> > - If PMD does not support one-pass EdDSA - well this is something that
> > should definitely discuss, but having any crypto internals in DPDK is
> > not probably an option?
> [Arek] - but, I have kept 'next' in later changes.
[Arek] - additionally if EdDSAhash one-pass used it is enough to have field with hash, an that's all - only information needed.
Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash option there is one additional hash - so enum in Ed struct should be enough.
> >
> > >
> > > > >
> > > > > > >
> > > > > > > > ---
> > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > 100644
> > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > >   * Structure describing asym xforms.
> > > > > > > >   */
> > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.13.6
Anoob Joseph May 27, 2022, 7:27 a.m. UTC | #10
Hi Arek,

Please see inline.

Thanks,
Anoob

> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Friday, May 27, 2022 12:26 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> 
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX
> > Sent: Friday, May 27, 2022 8:40 AM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX
> > > Sent: Friday, May 27, 2022 8:31 AM
> > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > > Hi Anoob,
> > >
> > > Sorry, I don't know how I have missed this email!
> > >
> > > > -----Original Message-----
> > > > From: Anoob Joseph <anoobj@marvell.com>
> > > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil
> > > > Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > <kirankumark@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > Hi Arek, Akhil,
> > > >
> > > > Please see inline.
> > > >
> > > > Thanks,
> > > > Anoob
> > > >
> > > > > -----Original Message-----
> > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > > Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > > <anoobj@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > > next xform
> > > > > >
> > > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > > Rationale behind having chaining in symmetric crypto was
> > > > > > > > > a fact that encryption and authentication are usually
> > > > > > > > > done on the same set of data independent of algorithm.
> > > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > > In asymmetric there is no such relation between
> > > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Arek Kusztal
> > > > > > > > > <arkadiuszx.kusztal@intel.com>
> > > > > > > >
> > > > > > > > Please check documentation
> > > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > > Diffie-Hellman private key generation followed by public
> generation.
> > > > > > > [Arek] And why do chaining when this can be done even with
> > > > > > > one bit
> > flag.
> > > > > > >
> > > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > > Kokkilagadda/Anoob please confirm.
> > > > > >
> > > > > > If we are removing it, then documentation should be in sync.
> > > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > > in ecdsa when k.data = NULL.
> > > > > But I do not see any situation for now it will be  useful, it
> > > > > may be dropped later if not application found.
> > > > > >
> > > > > > > Also, currently API does not support chaining of
> > > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > > [Arek] - This is one unlikely scenario to combine symmetric
> > > > > > > and asymmetric. One I can think of was once proposed DH +
> > > > > > > DSA integration for random number. But not much else,
> > > > > > > although we can keep it around for a
> > > > > > while.
> > > > > >
> > > > > > Yes it is highly unlikely to use this combination.
> > > >
> > > > [Anoob] We may need this support when we add EdDSA support. That
> > > > would involve a asymmetric operation after hash is generated (symmetric).
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.
> > > > org_wiki_EdDSA-
> 23Ed25519&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> > > > rwwviRSxyLWs2n6B-
> WYLn1v9SyTMrT5EQqh2TU&m=bddkY8ZMMGGHjFFvgGsyhfgWB
> > > > fuX0hpwqTdpgCAo_ngHINhO6zwLB-
> mUxNU8xu6p&s=3vFaBffulofGlfAPsjnaaUZa
> > > > V01o6k8XWzwNFWHQzvY&e=
> > > >
> > > > And, asymmetric chaining may become useful when we have PMDs
> > > > capable of doing more operations together (like the case with
> > > > EdDSA). So my preference would be to retain the 'next' field in asym crypto
> xform.
> > > [Arek] - that is very good point, however to implement EdDSA as
> > > chaining would mean that:
> > > - we need to implement EdDSA internals in DPDK
> > > - and EdDSA (in hash option, where actually picking hash would have
> > > sense) is not one hash but multiple hash operation, so we would have
> > > to had multiple chaining with operations in between
> > > - and we would have to compute R and S separately.
> > > - If PMD does not support one-pass EdDSA - well this is something
> > > that should definitely discuss, but having any crypto internals in
> > > DPDK is not probably an option?
> > [Arek] - but, I have kept 'next' in later changes.
> [Arek] - additionally if EdDSAhash one-pass used it is enough to have field with
> hash, an that's all - only information needed.
> Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash option
> there is one additional hash - so enum in Ed struct should be enough.

[Anoob] I'm also not clear about what would be the right abstraction. As you described for EdDSA, it can be just a flag. But we may need to revisit this when we add such kind of algos. So my suggestion was to not remove 'next' field just yet. We can revisit this sometime later.

Thanks for agreeing to the suggestion and keeping the field.
 
> > >
> > > >
> > > > > >
> > > > > > > >
> > > > > > > > > ---
> > > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > > 100644
> > > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > > >   * Structure describing asym xforms.
> > > > > > > > >   */
> > > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 2.13.6
Kusztal, ArkadiuszX May 27, 2022, 7:47 a.m. UTC | #11
> -----Original Message-----
> From: Anoob Joseph <anoobj@marvell.com>
> Sent: Friday, May 27, 2022 9:28 AM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>
> Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next xform
> 
> Hi Arek,
> 
> Please see inline.
> 
> Thanks,
> Anoob
> 
> > -----Original Message-----
> > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > Sent: Friday, May 27, 2022 12:26 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > <kirankumark@marvell.com>
> > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > xform
> >
> >
> >
> > > -----Original Message-----
> > > From: Kusztal, ArkadiuszX
> > > Sent: Friday, May 27, 2022 8:40 AM
> > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > <kirankumark@marvell.com>
> > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto next
> > > xform
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kusztal, ArkadiuszX
> > > > Sent: Friday, May 27, 2022 8:31 AM
> > > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > > <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > <kirankumark@marvell.com>
> > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > next xform
> > > >
> > > > Hi Anoob,
> > > >
> > > > Sorry, I don't know how I have missed this email!
> > > >
> > > > > -----Original Message-----
> > > > > From: Anoob Joseph <anoobj@marvell.com>
> > > > > Sent: Wednesday, May 25, 2022 9:06 AM
> > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Akhil
> > > > > Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran Kumar
> > > > > Kokkilagadda <kirankumark@marvell.com>
> > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>; Umesh Kartha
> > > > > <ukartha@marvell.com>; Ramkumar Balu <rbalu@marvell.com>
> > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > next xform
> > > > >
> > > > > Hi Arek, Akhil,
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > Thanks,
> > > > > Anoob
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> > > > > > Sent: Wednesday, May 25, 2022 12:06 PM
> > > > > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kiran
> > > > > > Kumar Kokkilagadda <kirankumark@marvell.com>; Anoob Joseph
> > > > > > <anoobj@marvell.com>
> > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym crypto
> > > > > > next xform
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > > > Sent: Wednesday, May 25, 2022 8:06 AM
> > > > > > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> > > > > > > dev@dpdk.org; Kiran Kumar Kokkilagadda
> > > > > > > <kirankumark@marvell.com>; Anoob Joseph <anoobj@marvell.com>
> > > > > > > Cc: Zhang, Roy Fan <roy.fan.zhang@intel.com>
> > > > > > > Subject: RE: [EXT] [PATCH 11/40] cryptodev: remove asym
> > > > > > > crypto next xform
> > > > > > >
> > > > > > > > > > - removed asymnetric crypto xform next field.
> > > > > > > > > > Rationale behind having chaining in symmetric crypto
> > > > > > > > > > was a fact that encryption and authentication are
> > > > > > > > > > usually done on the same set of data independent of algorithm.
> > > > > > > > > > HW usually will be able to handle it in one PCI call.
> > > > > > > > > > In asymmetric there is no such relation between
> > > > > > > > > > algorithms, therefore next field would be useless.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Arek Kusztal
> > > > > > > > > > <arkadiuszx.kusztal@intel.com>
> > > > > > > > >
> > > > > > > > > Please check documentation
> > > > "doc/guides/prog_guide/cryptodev_lib.rst"
> > > > > > > > > Not all asymmetric crypto xforms are supported for chaining.
> > > > > > > > > Currently supported asymmetric crypto chaining is
> > > > > > > > > Diffie-Hellman private key generation followed by public
> > generation.
> > > > > > > > [Arek] And why do chaining when this can be done even with
> > > > > > > > one bit
> > > flag.
> > > > > > > >
> > > > > > > I believe it is OK to remove next. @Kiran Kumar
> > > > > > > Kokkilagadda/Anoob please confirm.
> > > > > > >
> > > > > > > If we are removing it, then documentation should be in sync.
> > > > > > [Arek] - although, we may keep it for now, I am not dropping it in v2.
> > > > > > DH priv + pub can be done with priv_key.len = 0 -> similar as 'k'
> > > > > > in ecdsa when k.data = NULL.
> > > > > > But I do not see any situation for now it will be  useful, it
> > > > > > may be dropped later if not application found.
> > > > > > >
> > > > > > > > Also, currently API does not support chaining of
> > > > > > > > > symmetric and asymmetric crypto xforms.
> > > > > > > > [Arek] - This is one unlikely scenario to combine
> > > > > > > > symmetric and asymmetric. One I can think of was once
> > > > > > > > proposed DH + DSA integration for random number. But not
> > > > > > > > much else, although we can keep it around for a
> > > > > > > while.
> > > > > > >
> > > > > > > Yes it is highly unlikely to use this combination.
> > > > >
> > > > > [Anoob] We may need this support when we add EdDSA support. That
> > > > > would involve a asymmetric operation after hash is generated
> (symmetric).
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.
> > > > > org_wiki_EdDSA-
> > 23Ed25519&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=jPfB8
> > > > > rwwviRSxyLWs2n6B-
> > WYLn1v9SyTMrT5EQqh2TU&m=bddkY8ZMMGGHjFFvgGsyhfgWB
> > > > > fuX0hpwqTdpgCAo_ngHINhO6zwLB-
> > mUxNU8xu6p&s=3vFaBffulofGlfAPsjnaaUZa
> > > > > V01o6k8XWzwNFWHQzvY&e=
> > > > >
> > > > > And, asymmetric chaining may become useful when we have PMDs
> > > > > capable of doing more operations together (like the case with
> > > > > EdDSA). So my preference would be to retain the 'next' field in
> > > > > asym crypto
> > xform.
> > > > [Arek] - that is very good point, however to implement EdDSA as
> > > > chaining would mean that:
> > > > - we need to implement EdDSA internals in DPDK
> > > > - and EdDSA (in hash option, where actually picking hash would
> > > > have
> > > > sense) is not one hash but multiple hash operation, so we would
> > > > have to had multiple chaining with operations in between
> > > > - and we would have to compute R and S separately.
> > > > - If PMD does not support one-pass EdDSA - well this is something
> > > > that should definitely discuss, but having any crypto internals in
> > > > DPDK is not probably an option?
> > > [Arek] - but, I have kept 'next' in later changes.
> > [Arek] - additionally if EdDSAhash one-pass used it is enough to have
> > field with hash, an that's all - only information needed.
> > Normally EdDSA hash is fixed to SHA256 or BLAKE but for EdDSAhash
> > option there is one additional hash - so enum in Ed struct should be enough.
> 
> [Anoob] I'm also not clear about what would be the right abstraction. As you
> described for EdDSA, it can be just a flag. But we may need to revisit this when
> we add such kind of algos. So my suggestion was to not remove 'next' field just
> yet. We can revisit this sometime later.
> 
> Thanks for agreeing to the suggestion and keeping the field.
[Arek] - I considered few Ed options:
- or to have
Ed25519_op, Ed448_op,
- or 
EdDSA with
Curve_is = curve25519 (29) | curve448 (30)

By default hash algorithms are SHA2-56 and BLAKE accordingly.
But for preHash Ed there would be hash field:
Hash = [ rte_crypto_auth ]

/* When preHash (PH(M)) used this field is obligatory etc... */
> 
> > > >
> > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >  lib/cryptodev/rte_crypto_asym.h | 2 --
> > > > > > > > > >  1 file changed, 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > b/lib/cryptodev/rte_crypto_asym.h index
> > > > > > > > > > 1652a434a5..b355cbe5fa
> > > > > > > > > > 100644
> > > > > > > > > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > > > > > > > > @@ -492,8 +492,6 @@ struct rte_crypto_ecpm_op_param {
> > > > > > > > > >   * Structure describing asym xforms.
> > > > > > > > > >   */
> > > > > > > > > >  struct rte_crypto_asym_xform {
> > > > > > > > > > -	struct rte_crypto_asym_xform *next;
> > > > > > > > > > -	/**< Pointer to next xform to set up xform chain.*/
> > > > > > > > > >  	enum rte_crypto_asym_xform_type xform_type;
> > > > > > > > > >  	/**< Asymmetric crypto transform */
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.13.6
diff mbox series

Patch

diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 1652a434a5..b355cbe5fa 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -492,8 +492,6 @@  struct rte_crypto_ecpm_op_param {
  * Structure describing asym xforms.
  */
 struct rte_crypto_asym_xform {
-	struct rte_crypto_asym_xform *next;
-	/**< Pointer to next xform to set up xform chain.*/
 	enum rte_crypto_asym_xform_type xform_type;
 	/**< Asymmetric crypto transform */