[00/10] security: add software synchronous crypto process
mbox series

Message ID 20190906131330.40185-1-roy.fan.zhang@intel.com
Headers show
Series
  • security: add software synchronous crypto process
Related show

Message

Zhang, Roy Fan Sept. 6, 2019, 1:13 p.m. UTC
This RFC patch adds a way to rte_security to process symmetric crypto
workload in bulk synchronously for SW crypto devices.

Originally both SW and HW crypto PMDs works under rte_cryptodev to
process the crypto workload asynchronously. This way provides uniformity
to both PMD types but also introduce unnecessary performance penalty to
SW PMDs such as extra SW ring enqueue/dequeue steps to "simulate"
asynchronous working manner and unnecessary HW addresses computation.

We introduce a new way for SW crypto devices that perform crypto operation
synchronously with only fields required for the computation as input.

In rte_security, a new action type "RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO"
is introduced. This action type allows the burst of symmetric crypto
workload using the same algorithm, key, and direction being processed by
CPU cycles synchronously. This flexible action type does not require
external hardware involvement.

This patch also includes the announcement of a new API
"rte_security_process_cpu_crypto_bulk". With this API the packet is sent to
the crypto device for symmetric crypto processing. The device will encrypt
or decrypt the buffer based on the session data specified and preprocessed
in the security session. Different than the inline or lookaside modes, when
the function exits, the user will expect the buffers are either processed
successfully, or having the error number assigned to the appropriate index
of the status array.

The proof-of-concept AESNI-GCM and AESNI-MB SW PMDs are updated with the
support of this new method. To demonstrate the performance gain with
this method 2 simple performance evaluation apps under unit-test are added
"app/test: security_aesni_gcm_perftest/security_aesni_mb_perftest". The
users can freely compare their results against crypto perf application
results.

In the end, the ipsec library and ipsec-secgw sample application are also
updated to support this feature. Several test scripts are added to the
ipsec-secgw test-suite to prove the correctness of the implementation.

Fan Zhang (10):
  security: introduce CPU Crypto action type and API
  crypto/aesni_gcm: add rte_security handler
  app/test: add security cpu crypto autotest
  app/test: add security cpu crypto perftest
  crypto/aesni_mb: add rte_security handler
  app/test: add aesni_mb security cpu crypto autotest
  app/test: add aesni_mb security cpu crypto perftest
  ipsec: add rte_security cpu_crypto action support
  examples/ipsec-secgw: add security cpu_crypto action support
  doc: update security cpu process description

 app/test/Makefile                                  |    1 +
 app/test/meson.build                               |    1 +
 app/test/test_security_cpu_crypto.c                | 1326 ++++++++++++++++++++
 doc/guides/cryptodevs/aesni_gcm.rst                |    6 +
 doc/guides/cryptodevs/aesni_mb.rst                 |    7 +
 doc/guides/prog_guide/rte_security.rst             |  112 +-
 doc/guides/rel_notes/release_19_11.rst             |    7 +
 drivers/crypto/aesni_gcm/aesni_gcm_pmd.c           |   91 +-
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c       |   95 ++
 drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h   |   23 +
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c         |  291 ++++-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c     |   91 +-
 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h |   21 +-
 examples/ipsec-secgw/ipsec.c                       |   22 +
 examples/ipsec-secgw/ipsec_process.c               |    7 +-
 examples/ipsec-secgw/sa.c                          |   13 +-
 examples/ipsec-secgw/test/run_test.sh              |   10 +
 .../test/trs_3descbc_sha1_cpu_crypto_defs.sh       |    5 +
 .../test/trs_aescbc_sha1_cpu_crypto_defs.sh        |    5 +
 .../test/trs_aesctr_sha1_cpu_crypto_defs.sh        |    5 +
 .../ipsec-secgw/test/trs_aesgcm_cpu_crypto_defs.sh |    5 +
 .../test/trs_aesgcm_mb_cpu_crypto_defs.sh          |    7 +
 .../test/tun_3descbc_sha1_cpu_crypto_defs.sh       |    5 +
 .../test/tun_aescbc_sha1_cpu_crypto_defs.sh        |    5 +
 .../test/tun_aesctr_sha1_cpu_crypto_defs.sh        |    5 +
 .../ipsec-secgw/test/tun_aesgcm_cpu_crypto_defs.sh |    5 +
 .../test/tun_aesgcm_mb_cpu_crypto_defs.sh          |    7 +
 lib/librte_ipsec/esp_inb.c                         |  174 ++-
 lib/librte_ipsec/esp_outb.c                        |  290 ++++-
 lib/librte_ipsec/sa.c                              |   53 +-
 lib/librte_ipsec/sa.h                              |   29 +
 lib/librte_ipsec/ses.c                             |    4 +-
 lib/librte_security/rte_security.c                 |   16 +
 lib/librte_security/rte_security.h                 |   51 +-
 lib/librte_security/rte_security_driver.h          |   19 +
 lib/librte_security/rte_security_version.map       |    1 +
 36 files changed, 2791 insertions(+), 24 deletions(-)
 create mode 100644 app/test/test_security_cpu_crypto.c
 create mode 100644 examples/ipsec-secgw/test/trs_3descbc_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aescbc_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesctr_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesgcm_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/trs_aesgcm_mb_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_3descbc_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aescbc_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesctr_sha1_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesgcm_cpu_crypto_defs.sh
 create mode 100644 examples/ipsec-secgw/test/tun_aesgcm_mb_cpu_crypto_defs.sh

Comments

Aaron Conole Sept. 9, 2019, 12:43 p.m. UTC | #1
Fan Zhang <roy.fan.zhang@intel.com> writes:

> This RFC patch adds a way to rte_security to process symmetric crypto
> workload in bulk synchronously for SW crypto devices.
>
> Originally both SW and HW crypto PMDs works under rte_cryptodev to
> process the crypto workload asynchronously. This way provides uniformity
> to both PMD types but also introduce unnecessary performance penalty to
> SW PMDs such as extra SW ring enqueue/dequeue steps to "simulate"
> asynchronous working manner and unnecessary HW addresses computation.
>
> We introduce a new way for SW crypto devices that perform crypto operation
> synchronously with only fields required for the computation as input.
>
> In rte_security, a new action type "RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO"
> is introduced. This action type allows the burst of symmetric crypto
> workload using the same algorithm, key, and direction being processed by
> CPU cycles synchronously. This flexible action type does not require
> external hardware involvement.
>
> This patch also includes the announcement of a new API
> "rte_security_process_cpu_crypto_bulk". With this API the packet is sent to
> the crypto device for symmetric crypto processing. The device will encrypt
> or decrypt the buffer based on the session data specified and preprocessed
> in the security session. Different than the inline or lookaside modes, when
> the function exits, the user will expect the buffers are either processed
> successfully, or having the error number assigned to the appropriate index
> of the status array.
>
> The proof-of-concept AESNI-GCM and AESNI-MB SW PMDs are updated with the
> support of this new method. To demonstrate the performance gain with
> this method 2 simple performance evaluation apps under unit-test are added
> "app/test: security_aesni_gcm_perftest/security_aesni_mb_perftest". The
> users can freely compare their results against crypto perf application
> results.
>
> In the end, the ipsec library and ipsec-secgw sample application are also
> updated to support this feature. Several test scripts are added to the
> ipsec-secgw test-suite to prove the correctness of the implementation.
>
> Fan Zhang (10):
>   security: introduce CPU Crypto action type and API
>   crypto/aesni_gcm: add rte_security handler
>   app/test: add security cpu crypto autotest
>   app/test: add security cpu crypto perftest
>   crypto/aesni_mb: add rte_security handler
>   app/test: add aesni_mb security cpu crypto autotest
>   app/test: add aesni_mb security cpu crypto perftest
>   ipsec: add rte_security cpu_crypto action support
>   examples/ipsec-secgw: add security cpu_crypto action support
>   doc: update security cpu process description
>

Hi Fan,

This series has problem on aarch64:

   ../app/test/test_security_cpu_crypto.c:626:16: error: implicit declaration of function ‘rte_get_tsc_hz’ [-Werror=implicit-function-declaration]
     uint64_t hz = rte_get_tsc_hz(), time_start, time_now;
                   ^
   ../app/test/test_security_cpu_crypto.c:679:16: error: implicit declaration of function ‘rte_rdtsc’ [-Werror=implicit-function-declaration]
      time_start = rte_rdtsc();
                   ^
   ../app/test/test_security_cpu_crypto.c:711:16: error: implicit declaration of function ‘rte_get_timer_cycles’ [-Werror=implicit-function-declaration]
      time_start = rte_get_timer_cycles();
                   ^

I'm not sure best way to address this in the test - maybe there's a
better API to use for getting the cycles?