On Thu, May 11, 2017 at 06:05:29PM +0530, Umesh Kartha wrote: > This RFC contains specifications for asymmetric crypto algorithms. > Asymmetric crypto algorithms are essential part of protocols such as > SSL/TLS. As the current DPDK crypto library lacks support for asymmetric > crypto algorithms, this RFC is an attempt to address it. > > Cavium offers PCI hardware accelerators that supports symmetric and > asymmetric crypto algorithms, of which a few are addressed in this RFC. > Once specifications are agreed upon, I can submit a patch for the same. > We will develop a poll mode driver which can offload to OpenSSL crypto > library and to Cavium crypto accelerator. > > The asymmetric crypto algorithms supported in this version are: > This all appears to modify the cryptodev api, but I don't see where said modification was announced.
Additionally, I don't see modifications to a map file to export the api symbols. Have you tested this in a shared library build? Neil > 1 RSA > - RSA Sign > - RSA Verify > - RSA Public Encrypt > - RSA Private Decrypt > > Padding schemes supported for RSA operations are > * RSA PKCS#1 BT1 > * RSA PKCS#1 BT2 > * RSA PKCS#1 OAEP > * RSA PKCS#1 PSS > > 2 DH > - DH generate key > - DH compute key > > 3 ECDH > - ECDH generate key > - ECDH check key > - ECDH compute key > > 4 DSA > - DSA Sign > - DSA Verify > > 5 ECDSA > - ECDSA Sign > - ECDSA Verify > > 6 MODEXP > > 7 FUNDAMENTAL ECC > - Point Addition > - Point Multiplication > - Point Doubling > > 8 MODULAR INVERSE > > > Asymmetric crypto transform operations support both session oriented > mode and session less mode. If the operation is sessionless, an > asymmetric crypto transform structure, containing immutable parameters, > is passed along with per-operation mutable parameters in the structure. > Specific structures were written to contain immutable parameters > depending on algorithm used for crypto transform operation. The > parameters and type of transform is distinguished by the algorithm for > which the transform structure is filled. For a particular asymmetric > algorithm, not all parameters will be used and hence not required to be > filled. > > Changes from RFC v1: > > Added additional algorithms : DH/ECDH/MODINVERSE/DSA > Added additional curves for ECC operations: All cuves supported by libcrypto. > As per the comments received for RFC v1: > - removed mbufs from asymmetric crypto operation structure. > - added separate queue pair in device structure to handle asymmetric crypto > operations. > - added APIs to start/stop/initialize queue pairs to handle asymmetric crypto > operations. > - added asymmetric session structure and related APIs to handle session > operations (initialize/allocate/free) etc. > > RFC v1: http://dpdk.org/ml/archives/dev/2017-March/060869.html > > Umesh Kartha (3): > cryptodev: added asymmetric algorithms > cryptodev: asymmetric algorithm capability definitions > cryptodev: added asym queue pair, session apis > > lib/librte_cryptodev/rte_crypto.h | 135 +++- > lib/librte_cryptodev/rte_crypto_asym.h | 1124 > ++++++++++++++++++++++++++++++ > lib/librte_cryptodev/rte_cryptodev.c | 782 ++++++++++++++++++++- > lib/librte_cryptodev/rte_cryptodev.h | 414 +++++++++++ > lib/librte_cryptodev/rte_cryptodev_pmd.h | 113 +++ > 5 files changed, 2564 insertions(+), 4 deletions(-) > create mode 100644 lib/librte_cryptodev/rte_crypto_asym.h > > -- > 1.8.3.1 > >
