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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 4/10/2020 11:55 PM, Thomas Monjalon wrote:
> 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.

Hi Thomas,

I asked similar question, and there is already a detailed answer with some
background of the issue:
http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30@MN2PR11MB3550.namprd11.prod.outlook.com/

> 
> 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.
> "

Is it an issue to not have it in the 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.
> 
>