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 36160A057B; Tue, 14 Apr 2020 12:22:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 450851C1F3; Tue, 14 Apr 2020 12:22:03 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id D104F1C1DF for ; Tue, 14 Apr 2020 12:22:01 +0200 (CEST) IronPort-SDR: zkBuKXduJvcYuc6WDrRPzDgVzpgQ3d0/EB+XZ9GzjbmryPSbRMEyFow5I/1xQJnvIdeTJ4WkoZ aT8+3sIINDtA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2020 03:22:00 -0700 IronPort-SDR: Hy7yv2IM9rPm2lKkGjP7Fag6o7fFIDTKY+oXjUuQWI/1MgbAPMbRTnlNPbYVOloZWWoSX6mUka 34ChINTAt4pQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,382,1580803200"; d="scan'208";a="241950351" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.252.18.191]) ([10.252.18.191]) by orsmga007.jf.intel.com with ESMTP; 14 Apr 2020 03:21:56 -0700 To: Thomas Monjalon , 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, Anoob Joseph , Ruifeng Wang , Liron Himi , Nagadheeraj Rottela , Srikanth Jampala , Gagandeep Singh , Jay Zhou , Ravi Kumar References: <20200410142757.31508-1-david.coyle@intel.com> <4478083.44csPzL39Z@thomas> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJUBBMBCgA+AhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEAFiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl1meboFCQlupOoACgkQ+TPrQ98T YR9ACBAAv2tomhyxY0Tp9Up7mNGLfEdBu/7joB/vIdqMRv63ojkwr9orQq5V16V/25+JEAD0 60cKodBDM6HdUvqLHatS8fooWRueSXHKYwJ3vxyB2tWDyZrLzLI1jxEvunGodoIzUOtum0Ce gPynnfQCelXBja0BwLXJMplM6TY1wXX22ap0ZViC0m714U5U4LQpzjabtFtjT8qOUR6L7hfy YQ72PBuktGb00UR/N5UrR6GqB0x4W41aZBHXfUQnvWIMmmCrRUJX36hOTYBzh+x86ULgg7H2 1499tA4o6rvE13FiGccplBNWCAIroAe/G11rdoN5NBgYVXu++38gTa/MBmIt6zRi6ch15oLA Ln2vHOdqhrgDuxjhMpG2bpNE36DG/V9WWyWdIRlz3NYPCDM/S3anbHlhjStXHOz1uHOnerXM 1jEjcsvmj1vSyYoQMyRcRJmBZLrekvgZeh7nJzbPHxtth8M7AoqiZ/o/BpYU+0xZ+J5/szWZ aYxxmIRu5ejFf+Wn9s5eXNHmyqxBidpCWvcbKYDBnkw2+Y9E5YTpL0mS0dCCOlrO7gca27ux ybtbj84aaW1g0CfIlUnOtHgMCmz6zPXThb+A8H8j3O6qmPoVqT3qnq3Uhy6GOoH8Fdu2Vchh TWiF5yo+pvUagQP6LpslffufSnu+RKAagkj7/RSuZV25Ag0EV9ZMvgEQAKc0Db17xNqtSwEv mfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ESYpV8QWj0xK4YM0dLxnDU2IYxjEshSB1T qAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4AibPtrHuIXWQOBECcVZTTOdZYGAzaYzxiA ONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxDUQljeNvKYt1lZE/gAUUxNLWsYyTT+22/ vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35p iVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVjsM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQ I3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdcq9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYH fVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH71PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZ qw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFBVOQOxCvwRG2QCgcJ/UTn5vlivul+cThi 6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJl Rr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYCGwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNh HwUCXWZ5wAUJB3FgggAKCRD5M+tD3xNhH2O+D/9OEz62YuJQLuIuOfL67eFTIB5/1+0j8Tsu o2psca1PUQ61SZJZOMl6VwNxpdvEaolVdrpnSxUF31kPEvR0Igy8HysQ11pj8AcgH0a9FrvU /8k2Roccd2ZIdpNLkirGFZR7LtRw41Kt1Jg+lafI0efkiHKMT/6D/P1EUp1RxOBNtWGV2hrd 0Yg9ds+VMphHHU69fDH02SwgpvXwG8Qm14Zi5WQ66R4CtTkHuYtA63sS17vMl8fDuTCtvfPF HzvdJLIhDYN3Mm1oMjKLlq4PUdYh68Fiwm+boJoBUFGuregJFlO3hM7uHBDhSEnXQr5mqpPM 6R/7Q5BjAxrwVBisH0yQGjsWlnysRWNfExAE2sRePSl0or9q19ddkRYltl6X4FDUXy2DTXa9 a+Fw4e1EvmcF3PjmTYs9IE3Vc64CRQXkhujcN4ZZh5lvOpU8WgyDxFq7bavFnSS6kx7Tk29/ wNJBp+cf9qsQxLbqhW5kfORuZGecus0TLcmpZEFKKjTJBK9gELRBB/zoN3j41hlEl7uTUXTI JQFLhpsFlEdKLujyvT/aCwP3XWT+B2uZDKrMAElF6ltpTxI53JYi22WO7NH7MR16Fhi4R6vh FHNBOkiAhUpoXRZXaCR6+X4qwA8CwHGqHRBfYFSU/Ulq1ZLR+S3hNj2mbnSx0lBs1eEqe2vh cA== Message-ID: Date: Tue, 14 Apr 2020 11:21:55 +0100 MIME-Version: 1.0 In-Reply-To: <4478083.44csPzL39Z@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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" 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. > >