From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6859FA0598; Sat, 11 Apr 2020 00:56:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 84B881D183; Sat, 11 Apr 2020 00:56:04 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 1D5241D170 for ; Sat, 11 Apr 2020 00:56:03 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 581CE5803C8; Fri, 10 Apr 2020 18:56:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 10 Apr 2020 18:56:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=WKXlwUU7fIHa/kL8Qe85mVFunPn8qMxr+YJWT90KfO0=; b=mnE9LejiDtUT h65r31tO5aQFSn00QJ0a4FriqU4ap4IhG5t3GErKSbESSAfmwffDuWNloR/pgrUt pOjayZ8MFONWX6RMn/34a/YiXpfyJXaayYa1MoxqXnxiH6nWYDcRUmkIoViHYGI5 i56KYFWNXdCjHGTpVNd2t3KsotRaUxc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=WKXlwUU7fIHa/kL8Qe85mVFunPn8qMxr+YJWT90Kf O0=; b=X6XAHDgUk/clT+ge0gDfnguWcnLV4owZEGpXZTAWZagZd80UeArQecG73 dojKwjjCe1P7vkFsityiWq33Bji6/c2cf8A/1GF5ENGQQIrnkHPrlQDfRREE4dLx Oig4xu/O2ZZcn3aX/CWS6sbXzCR9YW1PNIgMPqJPkrs6P+xJO1yBJnyIjmiP7jJO 0RO6yyr1md5LYFMSFit4yQZ8IMUCIJIYz5XjkzmlmfyXASRIN2oF8quWf8iPAQWf ataLDyc6zKQU9Xhy1mQ0fCVVnip3L1cTJU7YFL9ddjumBs3SomoFETdQpcfjJhNF t+hKdtslfMVws3e3fohcVQZC3kycA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdefgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinheptddurdhorhhgpdgtrggslhgvlhgrsghsrdgtohhmpdhithhurdhinhhtnecu kfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C21523280063; Fri, 10 Apr 2020 18:55:58 -0400 (EDT) From: Thomas Monjalon To: David Coyle Cc: dev@dpdk.org, declan.doherty@intel.com, fiona.trahe@intel.com, pablo.de.lara.guarch@intel.com, brendan.ryan@intel.com, shreyansh.jain@nxp.com, hemant.agrawal@nxp.com, akhil.goyal@nxp.com, ferruh.yigit@intel.com, Anoob Joseph , Ruifeng Wang , Liron Himi , Nagadheeraj Rottela , Srikanth Jampala , Gagandeep Singh , Jay Zhou , Ravi Kumar Date: Sat, 11 Apr 2020 00:55:57 +0200 Message-ID: <4478083.44csPzL39Z@thomas> In-Reply-To: <20200410142757.31508-1-david.coyle@intel.com> References: <20200410142757.31508-1-david.coyle@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.