Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing

[Thomas Monjalon <thomas@monjalon.net>]

Hi,

Adding more people (crypto PMD maintainers) as Cc.

10/04/2020 16:27, David Coyle:
> Introduction
> ============
> 
> This patchset adds a new AESNI-MB Multi-Function raw device PMD for
> utilizing multi-function capabilities of the Intel IPSec Multi Buffer
> library.
> 
> The aim of this rawdev PMD is to provide a way of combining one or more
> common packet-processing functions into a single operation, focused on
> DOCSIS and GPON MAC workloads. This allows these functions to be performed
> in parallel by the Intel IPSec Multi Buffer library. These functions
> include cryptography and CRC/BIP calculations. Performing these functions
> in parallel as a single operation can enable a significant performance
> improvement.

I don't know crypto but I don't think using rawdev for crypto operations
is an API improvement.

Repeating the initial comments from v1 (because got no reply):
"
As a first impression, I feel it is not the right API.
DPDK is based on classes: ethdev, crypto, compress, baseband, regex
I want to understand why your features cannot fit in a class.

I feel we will need a lot of time to discuss the design.
If you don't see any consensus on the design in the mailing list,
you should request an opinion from the Technical Board.

This feature is not a priority for 20.05 release.
By the way, it has not been announced in any roadmap.
"

> Background
> ==========
> 
> There are a number of byte-wise operations which are used across many
> access network data-plane pipelines, such as Cipher, CRC and
> Bit-Interleaved-Parity (BIP). Some prototyping has been done at Intel as
> part of the 01.org access-network-dataplanes project to prove that a
> significant performance improvement is possible when such byte-wise
> operations are combined into a single pass of packet data processing. This
> performance boost has been prototyped for both DOCSIS MAC data-plane and
> GPON MAC data-plane pipelines based on DPDK.
> 
> The original prototypes on 01.org used some protocol-specific modifications
> to the DPDK cryptodev library. In order to make this performance
> optimization consumable for network access equipment vendors, a better
> solution was required as CRC and BIP cannot be regarded as cryptographic
> algorithms.

Why not part of crypto?
If not crypto, is it a new API class? Which one?
Please do not say rawdev.


> Hence, the introduction of an AESNI-MB Multi-Function rawdev PMD. This
> PMD uses a new multi-function interface which allows different types of
> operations be combined together. Initially, only symmetric crypto and error
> detection (i.e. CRC and BIP) operations can be combined.
> 
> NOTE: In a future DPDK release, a QAT Multi-Function raw device will also
> be added. As multiple raw devices will share the same interface, the
> approach taken was to create a common interface (i.e. multi-function) which
> can be used by these devices. This both cuts down on code duplication
> across the devices and allows a DOCSIS or GPON MAC application to access
> multiple devices using the same interface.
> 
> 
> Use Cases
> =========
> 
> The primary use cases for the AESNI-MB Multi-Function interface have
> already been mentioned. These are:
> 
> - DOCSIS MAC: Crypto-CRC
>         - Order:
>                 - Downstream: CRC, Encrypt
>                 - Upstream: Decrypt, CRC
>         - Specifications:
>                 - Crypto: 128-bit AES-CFB encryption variant for DOCSIS as
>                   described in section 11.1 of DOCSIS 3.1 Security
>                   Specification
>                   (https://apps.cablelabs.com/specification/CM-SP-SECv3.1)
>                 - CRC: Ethernet 32-bit CRC as defined in
>                   Ethernet/[ISO/IEC 8802-3]
> 
> - GPON MAC: Crypto-CRC-BIP
>         - Order:
>                 - Downstream: CRC, Encrypt, BIP
>                 - Upstream: BIP, Decrypt, CRC
>         - Specifications:
>                 - Crypto: AES-128 [NIST FIPS-197] cipher, used in counter
>                   mode (AES-CTR), as described in [NIST SP800-38A].
>                 - CRC: Ethernet 32-bit CRC as defined in
>                   Ethernet/[ISO/IEC 8802-3]
>                 - BIP: 4-byte bit-interleaved even parity (BIP) field
>                   computed over the entire FS frame, refer to
>                   ITU-T G.989.3, sections 8.1.1.5 and 8.1.2.3
>                   (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=
>                    T-REC-G.989.3-201510-I!!PDF-E)
> 
> Note that support for both these chained operations is already available in
> the Intel IPSec Multi-Buffer library.
> 
> 
> Architecture
> ============
> 
> The following diagram shows where the AESNI-MB Multi-Function rawdev PMD
> fits in an overall application architecture.
> 
>   +------------------------------------------------+
>   |                                                |
>   |                  Application                   |
>   |    (e.g. vCMTS (DOCSIS), vOLT (GPON), etc.)    |
>   |                                                |
>   +------------------------------------------------+
>                           |
>   +-----------------------|------------------------+
>   |                       |                  DPDK  |
>   |                       |                        |
>   |             +---------------------+            |
>   |             |                     |            |
>   |             |     rte_rawdev      |            |
>   |             |                     |            |            NOTE:
>   |             +---------------------+        ____|______ 'MULTI-FUNCTION
>   |                    /      \              /     |          INTERFACE'
>   |                   /        \            /      |         is opaque to
>   |                  /          \          /       |          rte_rawdev
>   |       +--------------------------------+       |
>   |       |    MULTI-FUNCTION INTERFACE    |       |
>   |       +--------------------------------+       |
>   |       +------------+      +------------+       |
>   |       |  AESNI-MB  |      |    QAT     |       |
>   |       |  MULTI-FN  |      |  MULTI-FN  |       |
>   |       |   RAWDEV   |      |   RAWDEV   |       |
>   |       |    PMD     |      |    PMD     |       |
>   |       +------------+      +------------+       |           NOTE:
>   |              |                  |     \________|______ 'QAT MULTI-FN
>   |              |                  |              |         RAWDEV PMD'
>   +--------------|------------------|--------------+      will be added in
>                  |                  |                       later release
>           +------------+      +------------+
>           |  AESNI-MB  |      |   QAT HW   |
>           |   SW LIB   |      |            |
>           +------------+      +------------+
[...]
>  drivers/raw/common/Makefile                   |    8 +
>  drivers/raw/common/meson.build                |    7 +
>  drivers/raw/common/multi_fn/Makefile          |   27 +
>  drivers/raw/common/multi_fn/meson.build       |    9 +
>  .../multi_fn/rte_common_multi_fn_version.map  |   12 +
>  drivers/raw/common/multi_fn/rte_multi_fn.c    |  148 ++
>  drivers/raw/common/multi_fn/rte_multi_fn.h    |  438 +++++

From the explanations above, I don't understand what is the exact role
of the multi_fn interface. The comments in the patch 1 don't help either.
It just reminds me rte_security, which was, in my opinion, a bad design.