mbox series

[v6,0/8] add Nitrox crypto device support

Message ID 20190927062533.19005-1-rnagadheeraj@marvell.com (mailing list archive)
Headers
Series add Nitrox crypto device support |

Message

Nagadheeraj Rottela Sept. 27, 2019, 6:26 a.m. UTC 
  Add the Nitrox PMD to support Nitrox crypto device.
---
v6:
* Updated Nitrox cryptodev html guide.
* Updated release notes 19.11.

v5:
* Combined related changes together and merged into single patch.
* Defined macros for PCI vendor and device ids.
* Checking return value of nitrox_sym_pmd_destroy() in pci remove.
* Removed wrapper macro over RTE_CRYPTODEV_NAME_MAX_LEN.
* Added cryptodev feature flags in the code and documentation in 
  a patch where they are supported.
* Added capabilities in the patch where they are supported.
* Implemented nitrox_sym_dev_config() and validating the number
  of queue pairs requested in the config.
* Used RTE_SET_USED() in place of __rte_unused and added comments
  in empty functions.
* Removed empty lines which are not required.

v4:
* Added wmb between pending_count store and sr pointer store in enqueue
  operation. This is required to safely read sr in dequeue operation.

v3:
* Add SHA224 and SHA256 HMAC algorithms

v2:
* Fix compilation error on AARCH64.
* Fix checkpatch warning "UNNECESSARY_ELSE: else is not generally
  useful after a break or return".

Nagadheeraj Rottela (8):
  crypto/nitrox: add Nitrox PMD library
  crypto/nitrox: create Nitrox symmetric cryptodev
  crypto/nitrox: add software queue management functionality
  crypto/nitrox: add hardware queue management functionality
  crypto/nitrox: add session management operations
  crypto/nitrox: add burst enqueue and dequeue operations
  crypto/nitrox: add cipher auth crypto chain processing
  test/crypto: add tests for Nitrox PMD

 MAINTAINERS                                      |   7 +
 app/test/test_cryptodev.c                        |  52 ++
 app/test/test_cryptodev.h                        |   1 +
 app/test/test_cryptodev_aes_test_vectors.h       |  48 +-
 app/test/test_cryptodev_blockcipher.c            |   9 +-
 app/test/test_cryptodev_blockcipher.h            |   1 +
 config/common_base                               |   5 +
 doc/guides/cryptodevs/features/nitrox.ini        |  40 ++
 doc/guides/cryptodevs/index.rst                  |   1 +
 doc/guides/cryptodevs/nitrox.rst                 |  51 ++
 doc/guides/rel_notes/release_19_11.rst           |   5 +
 drivers/crypto/Makefile                          |   1 +
 drivers/crypto/meson.build                       |   4 +-
 drivers/crypto/nitrox/Makefile                   |  34 ++
 drivers/crypto/nitrox/meson.build                |  19 +
 drivers/crypto/nitrox/nitrox_csr.h               |  40 ++
 drivers/crypto/nitrox/nitrox_device.c            | 124 ++++
 drivers/crypto/nitrox/nitrox_device.h            |  22 +
 drivers/crypto/nitrox/nitrox_hal.c               | 236 ++++++++
 drivers/crypto/nitrox/nitrox_hal.h               | 165 +++++
 drivers/crypto/nitrox/nitrox_logs.c              |  14 +
 drivers/crypto/nitrox/nitrox_logs.h              |  15 +
 drivers/crypto/nitrox/nitrox_qp.c                | 115 ++++
 drivers/crypto/nitrox/nitrox_qp.h                | 108 ++++
 drivers/crypto/nitrox/nitrox_sym.c               | 733 +++++++++++++++++++++++
 drivers/crypto/nitrox/nitrox_sym.h               |  13 +
 drivers/crypto/nitrox/nitrox_sym_capabilities.c  |  99 +++
 drivers/crypto/nitrox/nitrox_sym_capabilities.h  |  12 +
 drivers/crypto/nitrox/nitrox_sym_ctx.h           |  84 +++
 drivers/crypto/nitrox/nitrox_sym_reqmgr.c        | 638 ++++++++++++++++++++
 drivers/crypto/nitrox/nitrox_sym_reqmgr.h        |  23 +
 drivers/crypto/nitrox/rte_pmd_nitrox_version.map |   3 +
 mk/rte.app.mk                                    |   1 +
 33 files changed, 2704 insertions(+), 19 deletions(-)
 create mode 100644 doc/guides/cryptodevs/features/nitrox.ini
 create mode 100644 doc/guides/cryptodevs/nitrox.rst
 create mode 100644 drivers/crypto/nitrox/Makefile
 create mode 100644 drivers/crypto/nitrox/meson.build
 create mode 100644 drivers/crypto/nitrox/nitrox_csr.h
 create mode 100644 drivers/crypto/nitrox/nitrox_device.c
 create mode 100644 drivers/crypto/nitrox/nitrox_device.h
 create mode 100644 drivers/crypto/nitrox/nitrox_hal.c
 create mode 100644 drivers/crypto/nitrox/nitrox_hal.h
 create mode 100644 drivers/crypto/nitrox/nitrox_logs.c
 create mode 100644 drivers/crypto/nitrox/nitrox_logs.h
 create mode 100644 drivers/crypto/nitrox/nitrox_qp.c
 create mode 100644 drivers/crypto/nitrox/nitrox_qp.h
 create mode 100644 drivers/crypto/nitrox/nitrox_sym.c
 create mode 100644 drivers/crypto/nitrox/nitrox_sym.h
 create mode 100644 drivers/crypto/nitrox/nitrox_sym_capabilities.c
 create mode 100644 drivers/crypto/nitrox/nitrox_sym_capabilities.h
 create mode 100644 drivers/crypto/nitrox/nitrox_sym_ctx.h
 create mode 100644 drivers/crypto/nitrox/nitrox_sym_reqmgr.c
 create mode 100644 drivers/crypto/nitrox/nitrox_sym_reqmgr.h
 create mode 100644 drivers/crypto/nitrox/rte_pmd_nitrox_version.map

Comments

Gavin Hu Sept. 28, 2019, 2:46 p.m. UTC | #1 
Hi Nagadheeraj,

I am no expert in crypto dev, maybe you can educate me if I am wrong: 
I got an impression in this series, the barriers were used too much, too heavily and unnecessarily. 

For enqueue operations, I understand they are stores to the DMA buffer, the queue will be fetched and updated by the crypto device after processing, then dequeued by the other CPU cores. So for enqueue operations, an rte_io_wmb is required before the doorbell ringing,  and an rte_smp_wmb is required to ensure the enqueue operations were done before the consumer on the other side(who dequeues) sees the updated pending_count. For dequeue operations, rte_smp_rmb is required after reading the pending_count to ensure reading the intact content from the queue(if the queue entries were not handled yet by the crypto dev, the status will show that, maybe an rte_io_rmb is required to ensure the status is read out first).

The rte_smp_xmb can even be optimized with C11 atomics, but it can be next step. 

Best Regards,
Gavin
Nagadheeraj Rottela Sept. 30, 2019, 1:40 p.m. UTC | #2 
Hi Gavin,

Thanks for your comments. Your suggestions are applicable in this case.
I will remove the usage of rte_wmb() and rte_rmb() in all places as they are not required.
I will add rte_smp_wmb() before pending count update in enqueue operation and add rte_smp_rmb() before reading softreq from pending queue.
I will add rte_io_wmb() before the ring doorbell to ensure all the DMA buffers & descriptors stores are completed.
We check command completion based on the completion code update (which is the last word in the output buffer) and hence rte_io_rmb() is not required.

Best Regards,
Dheeraj

> -----Original Message-----
> From: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> Sent: Saturday, September 28, 2019 8:17 PM
> To: Nagadheeraj Rottela <rnagadheeraj@marvell.com>;
> Akhil.goyal@nxp.com; pablo.de.lara.guarch@intel.com
> Cc: Srikanth Jampala <jsrikanth@marvell.com>; dev@dpdk.org; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology
> China) <Gavin.Hu@arm.com>; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: [EXT] RE: [PATCH v6 0/8] add Nitrox crypto device support
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Nagadheeraj,
> 
> I am no expert in crypto dev, maybe you can educate me if I am wrong:
> I got an impression in this series, the barriers were used too much, too
> heavily and unnecessarily.
> 
> For enqueue operations, I understand they are stores to the DMA buffer,
> the queue will be fetched and updated by the crypto device after processing,
> then dequeued by the other CPU cores. So for enqueue operations, an
> rte_io_wmb is required before the doorbell ringing,  and an rte_smp_wmb is
> required to ensure the enqueue operations were done before the consumer
> on the other side(who dequeues) sees the updated pending_count. For
> dequeue operations, rte_smp_rmb is required after reading the
> pending_count to ensure reading the intact content from the queue(if the
> queue entries were not handled yet by the crypto dev, the status will show
> that, maybe an rte_io_rmb is required to ensure the status is read out first).
> 
> The rte_smp_xmb can even be optimized with C11 atomics, but it can be
> next step.
> 
> Best Regards,
> Gavin