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/mn2pr11mb35507d4b96677a41e66440c5e3...@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. > >
