Hi Fiona, On Mon, May 29, 2017 at 02:51:11PM +0000, Trahe, Fiona wrote: > Hi Umesh, > > > -----Original Message----- > > From: Umesh Kartha [mailto:umesh.kar...@caviumnetworks.com] > > Sent: Friday, May 26, 2017 8:18 AM > > To: Trahe, Fiona <fiona.tr...@intel.com> > > Cc: dev@dpdk.org; Jerin Jacob <jerin.jacobkollanukka...@cavium.com>; > > Balasubramanian Manoharan > > <balasubramanian.manoha...@cavium.com>; Ram Kumar <ram.ku...@cavium.com>; > > Murthy > > Nidadavolu <nidadavolu.mur...@cavium.com>; Doherty, Declan > > <declan.dohe...@intel.com>; De Lara > > Guarch, Pablo <pablo.de.lara.gua...@intel.com> > > Subject: Re: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms > > > > Hi Fiona, > > > > > > On Thu, May 25, 2017 at 04:00:42PM +0000, Trahe, Fiona wrote: > > > Hi Umesh, > > > > > > > > > > -----Original Message----- > > > > From: Umesh Kartha [mailto:umesh.kar...@caviumnetworks.com] > > > > Sent: Thursday, May 11, 2017 1:36 PM > > > > To: dev@dpdk.org > > > > Cc: Jerin Jacob <jerin.jacobkollanukka...@cavium.com>; Balasubramanian > > > > Manoharan > > > > <balasubramanian.manoha...@cavium.com>; Ram Kumar > > > > <ram.ku...@cavium.com>; Murthy > > > > Nidadavolu <nidadavolu.mur...@cavium.com>; Doherty, Declan > > > > <declan.dohe...@intel.com>; De > > Lara > > > > Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Trahe, Fiona > > > > <fiona.tr...@intel.com> > > > > Subject: [RFC PATCH v2 1/3] cryptodev: added asymmetric algorithms > > > > > > > > Added asymmetric xform structures, operation definitions, operation > > > > parameters. Added asymmetric algorithms RSA, DH, ECDH, DSA, ECDSA, > > > > MODEXP, FECC, MOD-INVERSE. Added curves (all curves supported by > > > > libcrypto as of now). > > > > > > > > Signed-off-by: Umesh Kartha <umesh.kar...@caviumnetworks.com> > > > > --- > > > > lib/librte_cryptodev/rte_crypto_asym.h | 1124 > > > > ++++++++++++++++++++++++++++++++ > > > > 1 file changed, 1124 insertions(+) > > > > create mode 100644 lib/librte_cryptodev/rte_crypto_asym.h > > > > > > > > diff --git lib/librte_cryptodev/rte_crypto_asym.h > > > > lib/librte_cryptodev/rte_crypto_asym.h > > > > new file mode 100644 > > > > index 0000000..36a8b4f > > > > --- /dev/null > > > > +++ lib/librte_cryptodev/rte_crypto_asym.h > > > > @@ -0,0 +1,1124 @@ > > > > +/* > > > > + * BSD LICENSE > > > > + * > > > > + * Copyright (C) Cavium networks Ltd. 2017. > > > > + * > > > > + * Redistribution and use in source and binary forms, with or without > > > > + * modification, are permitted provided that the following conditions > > > > + * are met: > > > > + * > > > > + * * Redistributions of source code must retain the above copyright > > > > + * notice, this list of conditions and the following disclaimer. > > > > + * * Redistributions in binary form must reproduce the above > > > > copyright > > > > + * notice, this list of conditions and the following disclaimer > > > > in > > > > + * the documentation and/or other materials provided with the > > > > + * distribution. > > > > + * * Neither the name of Cavium Networks nor the names of its > > > > + * contributors may be used to endorse or promote products > > > > derived > > > > + * from this software without specific prior written permission. > > > > + * > > > > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > > > > CONTRIBUTORS > > > > + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > > > > + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > > > > FOR > > > > + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > > > > COPYRIGHT > > > > + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > > > > INCIDENTAL, > > > > + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > > > > + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF > > > > USE, > > > > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON > > > > ANY > > > > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR > > > > TORT > > > > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE > > > > USE > > > > + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH > > > > DAMAGE. > > > > + */ > > > > + > > > > +#ifndef _RTE_CRYPTO_ASYM_H_ > > > > +#define _RTE_CRYPTO_ASYM_H_ > > > > + > > > > +/** > > > > + * @file rte_crypto_asym.h > > > > + * > > > > + * RTE Definitions for Asymmetric Cryptography > > > > + * > > > > + * Defines asymmetric algorithms and modes, as well as supported > > > > + * asymmetric crypto operations. > > > > + */ > > > > + > > > > +#ifdef __cplusplus > > > > +extern "C" { > > > > +#endif > > > > + > > > > +#include <string.h> > > > > +#include <stdint.h> > > > > +#include <rte_mbuf.h> > > > > +#include <rte_memory.h> > > > > +#include <rte_mempool.h> > > > > +#include <rte_common.h> > > > > +#include "rte_crypto_sym.h" > > > > + > > > > +typedef struct rte_crypto_xform_param_t { > > > > + uint8_t *data; > > > > + size_t length; > > > > +} rte_crypto_xform_param; > > > > + > > > > +typedef struct rte_crypto_op_param_t { > > > > + uint8_t *data; > > > > + phys_addr_t phys_addr; > > > > + size_t length; > > > > +} rte_crypto_op_param; > > > [Fiona] Are both above lengths in bytes ? > > > > > > > > [Umesh] Yes, they are in bytes. Will add note for this to avoid any > > confusion. > [Fiona] Thanks. > Re your v1 question re sessionless, I don't see a strong need to support > sessions > in Asymm crypto and we would probably initially just implement the > SESSIONLESS case. > For that case, the rte_crypto_xform_param_t would be used to provide data to > the op. So providing a phys_addr would save an internal alloc and copy and > be necessary to optimise performance. > What do you think of adding this? > In that case the structs are identical, so can be combined. > > Regards, > Fiona >
If the general conscience is that a session is not required to perform asymmetric crypto operations, I will remove it. The only scenario in which an asymmetric session can be used is to generate DSA/ECDSA/RSA signatures multiple times. Alternatively, crypto_asym_xform struct can be reused in this scenario. And yes, as you suggested, we can combine the structs. Regards, Umesh
