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 706B5A2EEB for ; Thu, 12 Sep 2019 16:12:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1A1FA1E9AD; Thu, 12 Sep 2019 16:12:27 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) by dpdk.org (Postfix) with ESMTP id 64A231E971 for ; Thu, 12 Sep 2019 16:12:25 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iZufDJsDrmjGYO0Sst3WvNI6sU2lnDWlozwM4PNBtyUEXG8XsXrUmdOlopp43CIj/4sQycEDl7L0ILWJLJU127RpTCjq4DW8QRBNTBxHIIbb7tppznEI5jfrqjoDmUQUCjn44Z37jUAxcExS8EqIuz84ixr16j4l7tr9J0jVygRVR4nGGQ/QA7ZCmslJGZOprp1e4xN+CyWVOAtquEAwX7UJhTBnoXjIHyK5HcpgnrO2TBI2DzDjCizw2++tBf/H3xK0sfoOundYEzNxKHl6yZ67ZSqLqnlFZjLa2lKpJI5PbqIUCX91hi3FkkQRJMjE84kJEmfakEOueUt6ApJZ0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wKPLfx50E5FDu2FAf5os+3ryyp6blB6HPEdvJFcoC2o=; b=YIoGxOHpgMvr/10EdzOIsoUoT1Fb1l/dzkmKyfCf/PMYe4biEx30wTplnLXkNXnF2x9hugXdl1eQs/EY7yANWxkVQAfV6J+D9f/vmjuZogSUOJf+zQm6IwQYRKWXYgzEPE/ip1WJZFlZJ140AHKKDr7p5ykxg2pS1H4U+KMfene2nRBObuPxeouDzVTUK1NS9PSKN+vtPZhTvS8P59yH369ga9XBofSOYUSNV4sReSRdEFTQxA79WEXeCzh2ltntfZjuoor0Ju5a2q7BMRqxya8AreaHZAZ3y0Gn4bYaOOscgaqCt17qE3VE1dRrFeUYoHQWiM2EKtSkkGEFDN+EAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wKPLfx50E5FDu2FAf5os+3ryyp6blB6HPEdvJFcoC2o=; b=qfdCiBAdn6evTX1tQH+13/bumqsgkaBRgndjtfAXlFedLnZnYpLekWHh48GkOvbSniCQAdC33ZLyNxazaDpubLhZ2u/mML3NOJQgZ2Cqcw5sTc/9fuoprSdxlNLNcSjdwUeAanzzJ0/9yZA+263Dxeb10e2iuAUnlgz4jz+i3lM= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6735.eurprd04.prod.outlook.com (20.179.235.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Thu, 12 Sep 2019 14:12:24 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::7092:d719:df0b:2b70]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::7092:d719:df0b:2b70%7]) with mapi id 15.20.2241.022; Thu, 12 Sep 2019 14:12:24 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "dev@dpdk.org" , "De Lara Guarch, Pablo" , Thomas Monjalon CC: "Zhang, Roy Fan" , "Doherty, Declan" , Anoob Joseph Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAAT02AgAYXC5CAAbSDgIABbRGg Date: Thu, 12 Sep 2019 14:12:23 +0000 Message-ID: References: <20190903154046.55992-1-roy.fan.zhang@intel.com> <20190903154046.55992-2-roy.fan.zhang@intel.com> <9F7182E3F746AB4EA17801C148F3C6043369D686@IRSMSX101.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191926A17@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191962CD5@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580191962CD5@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-Mentions: pablo.de.lara.guarch@intel.com,thomas@monjalon.net X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [171.48.41.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afd37785-0e9d-4a29-a4c5-08d7378b3c04 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6735; x-ms-traffictypediagnostic: VE1PR04MB6735: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(366004)(376002)(189003)(199004)(13464003)(66556008)(14454004)(3846002)(66946007)(86362001)(186003)(476003)(25786009)(99286004)(6436002)(7696005)(6246003)(76176011)(486006)(256004)(71190400001)(71200400001)(14444005)(76116006)(64756008)(66446008)(66476007)(52536014)(26005)(229853002)(2501003)(74316002)(305945005)(8676002)(2906002)(15650500001)(66066001)(8936002)(81166006)(102836004)(9686003)(5660300002)(33656002)(53546011)(7736002)(44832011)(81156014)(11346002)(110136005)(446003)(54906003)(55016002)(478600001)(316002)(4326008)(53936002)(6116002)(6506007)(156664002); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6735; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5EonxwYEsY5zslp94/RwjxG1Ijvwdsj9viY+3qRTr7K0AYhd4rjYuWuys/Y9y439ocbrvYm6Phou5UZlb3UXMxJzpnLUl/7ABS+6hm4GfeIJLrG+1GWobp0ZgO4bdaODk7ljhwqZdHLbmgw8Azmebyp4NJ2YEQlpFvKFMme75pOFKiMWIkaUoyr7m6Rw25P8/gL79gS+b5o5gZhR6KDz9lx5WikMTj/WtTzKfS3g7idPZBoXP9lD5z4LBL1AbmjxcHZ9pAGwMK0Tz/GlZm95VAQ7VbjZjT1eNZMu5b4O0R78Ukq1VY7xXuAbr3aGdB0IA9ZB1jFNvTj8yIoJUVrP4YGsVKTGYoSx9zJDa8gBi+cE9eKofunvHkXbbnTmuydw4474deaOenJjRMiElEZ5kzKeBpC/3flrmT4NzpR5c3A= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: afd37785-0e9d-4a29-a4c5-08d7378b3c04 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 14:12:24.0125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XuBWHZ4dO3cbK47vEP+thIi1l1t6yIuQO8DRJDDAznz+CJ+ntzJLtpZ0QNK/ew02GiX0jq8oZlfXpndEpFsA5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6735 Subject: Re: [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API 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 Konstantin, > Hi Akhil, > > > > > > > > This action type allows the burst of symmetric crypto workload us= ing the > > > same > > > > > algorithm, key, and direction being processed by CPU cycles > synchronously. > > > > > This flexible action type does not require external hardware invo= lvement, > > > > > having the crypto workload processed synchronously, and is more > > > performant > > > > > than Cryptodev SW PMD due to the saved cycles on removed "async > mode > > > > > simulation" as well as 3 cacheline access of the crypto ops. > > > > > > > > Does that mean application will not call the cryptodev_enqueue_burs= t and > > > corresponding dequeue burst. > > > > > > Yes, instead it just call rte_security_process_cpu_crypto_bulk(...) > > > > > > > It would be a new API something like process_packets and it will ha= ve the > > > crypto processed packets while returning from the API? > > > > > > Yes, though the plan is that API will operate on raw data buffers, no= t mbufs. > > > > > > > > > > > I still do not understand why we cannot do with the conventional cr= ypto lib > > > only. > > > > As far as I can understand, you are not doing any protocol processi= ng or > any > > > value add > > > > To the crypto processing. IMO, you just need a synchronous crypto > processing > > > API which > > > > Can be defined in cryptodev, you don't need to re-create a crypto s= ession > in > > > the name of > > > > Security session in the driver just to do a synchronous processing. > > > > > > I suppose your question is why not to have > > > rte_crypot_process_cpu_crypto_bulk(...) instead? > > > The main reason is that would require disruptive changes in existing > cryptodev > > > API > > > (would cause ABI/API breakage). > > > Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO need some extra > > > information > > > that normal crypto_sym_xform doesn't contain > > > (cipher offset from the start of the buffer, might be something extra= in > future). > > > > Cipher offset will be part of rte_crypto_op. >=20 > fill/read (+ alloc/free) is one of the main things that slowdown current = crypto-op > approach. > That's why the general idea - have all data that wouldn't change from pac= ket to > packet > included into the session and setup it once at session_init(). I agree that you cannot use crypto-op. You can have the new API in crypto. As per the current patch, you only need cipher_offset which you can have it= as a parameter until You get it approved in the crypto xform. I believe it will be beneficial in= case of other crypto cases as well. We can have cipher offset at both places(crypto-op and cipher_xform). It wi= ll give flexibility to the user to override it. >=20 > > If you intend not to use rte_crypto_op > > You can pass this as an argument in the new cryptodev API. >=20 > You mean extra parameter in rte_security_process_cpu_crypto_bulk()? > It can be in theory, but that solution looks a bit ugly: > why to pass for each call something that would be constant per session? > Again having that value constant per session might allow some extra > optimisations > That would be hard to achieve for dynamic case. > and not extendable: > Suppose tomorrow will need to add something extra (some new algorithm > support or so). > With what you proposing will need to new parameter to the function, > which means API breakage. >=20 > > Something extra will also cause ABI breakage in security as well. > > So it will be same. >=20 > I don't think it would. > AFAIK, right now this patch doesn't introduce any API/ABI breakage. > Iinside struct rte_security_session_conf we have a union of xforms > depending on session type. > So as long as cpu_crypto_xform wouldn't exceed sizes of other xform - > I believe no ABI breakage will appear. Agreed, it will not break ABI in case of security till we do not exceed cur= rent size. Saving an ABI/API breakage is more important or placing the code at the cor= rect place. We need to find a tradeoff. Others can comment on this. @Thomas Monjalon, @De Lara Guarch, Pablo Any comments? >=20 >=20 > > > > > Also right now there is no way to add new type of crypto_sym_session > without > > > either breaking existing crypto-dev ABI/API or introducing new struct= ure > > > (rte_crypto_sym_cpu_session or so) for that. > > > > What extra info is required in rte_cryptodev_sym_session to get the > rte_crypto_sym_cpu_session. >=20 > Right now - just cipher_offset (see above). > What else in future (if any) - don't know. >=20 > > I don't think there is any. > > I believe the same crypto session will be able to work synchronously as= well. >=20 > Exactly the same - problematically, see above. >=20 > > We would only need a new API to perform synchronous actions. > > That will reduce the duplication code significantly > > in the driver to support 2 different kind of APIs with similar code ins= ide. > > Please correct me in case I am missing something. >=20 > To add new API into crypto-dev would also require changes in the PMD, > it wouldn't come totally free and I believe would require roughly the sam= e > amount of changes. It will be required only in the PMDs which support it and would be minimal. You would need a feature flag, support for that synchronous API. Session i= nformation will already be there in the session. The changes wrt cipher_offset need to be a= dded but with some default value to identify override will be done or not. >=20 > > > > > > > While rte_security is designed in a way that we can add new session t= ypes > and > > > related parameters without causing API/ABI breakage. > > > > Yes the intent is to add new sessions based on various protocols that c= an be > supported by the driver. >=20 > Various protocols and different types of sessions (and devices they belon= g to). > Let say right now we have INLINE_CRYPTO, INLINE_PROTO, LOOKASIDE_PROTO, > etc. > Here we introduce new type of session. What is the new value add to the existing sessions. The changes that we are= doing here is just to avoid an API/ABI breakage. The synchronous processing can h= appen on both crypto and security session. This would mean, only the processing API shoul= d be defined, rest all should be already there in the sessions. In All other cases, INLINE - eth device was not having any format to perfor= m crypto op LOOKASIDE - PROTO - add protocol specific sessions which is not available i= n crypto. >=20 > > It is not that we should find it as an alternative to cryptodev and usi= ng it just > because it will not cause > > ABI/API breakage. >=20 > I am considering this new API as an alternative to existing ones, but as = an > extension. > Existing crypto-op API has its own advantages (generic), and I think we s= hould > keep it supported by all crypto-devs. > From other side rte_security is an extendable framework that suits the pu= rpose: > allows easily (and yes without ABI breakage) introduce new API for specia= l type > of crypto-dev (SW based). >=20 >=20 Adding a synchronous processing API is understandable and can be added in b= oth Crypto as well as Security, but a new action type for it is not required. Now whether to support that, we have ABI/API breakage, that is a different = issue. And we may have to deal with it if no other option is there. >=20 >=20 >=20 > > IMO the code should be placed where its intent is. > > > > > > > > BTW, what is your concern with proposed approach (via rte_security)? > > > From my perspective it is a lightweight change and it is totally opti= onal > > > for the crypto PMDs to support it or not. > > > Konstantin > > > > > > > > > > > > > AESNI-GCM and AESNI-MB PMDs are updated with this support. There = is > a > > > small > > > > > performance test app under app/test/security_aesni_gcm(mb)_perfte= st > to > > > > > prove. > > > > > > > > > > For the new API > > > > > The packet is sent to the crypto device for symmetric crypto > > > > > processing. The device will encrypt or decrypt the buffer based o= n the > > > session > > > > > data specified and preprocessed in the security session. Differen= t > > > > > than the inline or lookaside modes, when the function exits, the = user will > > > > > expect the buffers are either processed successfully, or having t= he error > > > number > > > > > assigned to the appropriate index of the status array. > > > > > > > > > > Will update the program's guide in the v1 patch. > > > > > > > > > > Regards, > > > > > Fan > > > > > > > > > > > -----Original Message----- > > > > > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > > > > > > Sent: Wednesday, September 4, 2019 11:33 AM > > > > > > To: Zhang, Roy Fan ; dev@dpdk.org > > > > > > Cc: Ananyev, Konstantin ; Doherty= , > > > Declan > > > > > > ; De Lara Guarch, Pablo > > > > > > > > > > > > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto act= ion > type > > > and > > > > > > API > > > > > > > > > > > > Hi Fan, > > > > > > > > > > > > > > > > > > > > This patch introduce new > RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > > > > > > action > > > > > > > type to security library. The type represents performing cryp= to > > > > > > > operation with CPU cycles. The patch also includes a new API = to > > > > > > > process crypto operations in bulk and the function pointers f= or PMDs. > > > > > > > > > > > > > I am not able to get the flow of execution for this action type= . Could > you > > > > > > please elaborate the flow in the documentation. If not in > documentation > > > > > > right now, then please elaborate the flow in cover letter. > > > > > > Also I see that there are new APIs for processing crypto operat= ions in > bulk. > > > > > > What does that mean. How are they different from the existing A= PIs > which > > > > > > are also handling bulk crypto ops depending on the budget. > > > > > > > > > > > > > > > > > > -Akhil