[dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing
Ferruh Yigit
ferruh.yigit at intel.com
Tue Apr 14 12:21:55 CEST 2020
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.
>
>
More information about the dev
mailing list