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 A5E7BA2EEB for ; Tue, 10 Sep 2019 13:25:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 73E561E85D; Tue, 10 Sep 2019 13:25:29 +0200 (CEST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) by dpdk.org (Postfix) with ESMTP id 4A4591C29A for ; Tue, 10 Sep 2019 13:25:28 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7lH9Qdwn7+w5eq9n6bP9Ec02sxSOMEFAESKc3WAS7sxP5fA7Kk/5vjfYZYx4PfbUCS6aJexPtZoOeypaHuufuqKkszxFtcytJclG7GOxgoy3gjyPx00SmcYNC6/Ydm1sUtVwZdTb4G5qZK7ShdfPqZOBTiyZYCwGzlg9a72okFPB2dB6eu564KjZHJfCk4qN8IO4ZzAxlBZUR9NBJCmocPgf+sSFjIQzHef83Eii+YhYtWaxFdeBqNheq4aXZoaLDO+agasQg29q3fxFiqTPWSsRMaanaG13gEO+xbVYjqXENvkQSlXynYaNeIfhK7u1CFEz+lu/1gpUNK9/3DB2Q== 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=K32gxjpCWJHk1+loP4Wx4Y2yI9ynOdmQAYH7V/3AE1o=; b=YaddDRnQUF+fgZc6kr7zUkpoPyvzmYo9B9c8g5sxb/bRX2ZFohwb+EV3tNYQ074QHCJe0jtnbvbKFE/l0wv0hiKDCz2warCLz+fZNzn46CigqqEVrzTkLIapngEHZGWSvmtg+9oMN/WVx3WxqdMkLguLjlc5pgwHAaAXOCAfe0h1Zn/A5vH/O9QzTpbu4LwkNaJcWJzkG7nots/IEpI+WGKNH1fVSvVgLY2Wh00D8Wg/Oyf7PBOV6DSihsgN9e3Jq92Bsre8yDCVDVOujZA0T8zvObsyYahck9Mu4Sg9/VnR+MvRISnGNaI7GCHtK4Jp968w9wDqaN9LKEtvxQgDMw== 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=K32gxjpCWJHk1+loP4Wx4Y2yI9ynOdmQAYH7V/3AE1o=; b=V5ZphS9u0nzXQicY6j8RFucnAUQJj+1cpNdgIDNwjaz1JwS7sIHPIXpF1QMQ3MV5Zsdb4ukf/1n8EkL5bt/JWwWTuR1P1JVDz0wvX9rnU+Z1xReoGEI8p+Ok3X6EmLlf0Y3Lr2Bn+rCgAN44RhjZGREipbKhTqbmlBD0yJpw0fw= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6431.eurprd04.prod.outlook.com (20.179.232.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.15; Tue, 10 Sep 2019 11:25:27 +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.018; Tue, 10 Sep 2019 11:25:27 +0000 From: Akhil Goyal To: "Zhang, Roy Fan" , "dev@dpdk.org" CC: "Ananyev, Konstantin" , "Doherty, Declan" , "De Lara Guarch, Pablo" Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4LqyJkewM9NkuUWAfAmrqx1acbUiZggAAsN4CAAtsIgIAASzSAgAYlzeA= Date: Tue, 10 Sep 2019 11:25:26 +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> <9F7182E3F746AB4EA17801C148F3C604336AF46E@IRSMSX101.ger.corp.intel.com> In-Reply-To: <9F7182E3F746AB4EA17801C148F3C604336AF46E@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1b9ba19c-7020-4d38-3cc2-08d735e1947e 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:VE1PR04MB6431; x-ms-traffictypediagnostic: VE1PR04MB6431: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(366004)(136003)(39860400002)(376002)(13464003)(199004)(189003)(102836004)(81166006)(81156014)(6246003)(256004)(229853002)(7736002)(44832011)(99286004)(9686003)(5024004)(6436002)(476003)(2906002)(55016002)(11346002)(478600001)(2501003)(74316002)(446003)(6506007)(53546011)(316002)(7696005)(14454004)(71190400001)(54906003)(26005)(25786009)(6116002)(3846002)(71200400001)(305945005)(86362001)(8676002)(33656002)(4326008)(5660300002)(64756008)(66066001)(186003)(66446008)(52536014)(14444005)(76176011)(486006)(53936002)(66946007)(66476007)(76116006)(110136005)(66556008)(8936002)(15650500001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6431; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: NXOS0W27c/sJEyEqSnkyPt56FAbr+LK40V+ltD/LKnay0HadncqRbzINab0KPmwY2bbQGzjbfSx8VIDrlt4ahA17zt/IQo1MVz1l8/IHmeMBDTHFOGaVtqd2Q9E/ogYRvBozjOvLVF9nycjzDRiwLvRTFOj9VZmtMuNvmv95BpMkj02PWP3QxzST9o0iIbLfeTTg3KqxPIPfRnVqTk/7eQYLO/pdA4wZk7OaN5QmlBvEPxKQmegba0mNdFDCXc8g/En+Z7goY+rlCDK2IldVSfUO595xJ3HUlzFDdtPL6rpPviPRV8NIlfOyIVmc5Qw7+mKRXtVMl7g42GSQYiDTaujeKVuJc7sSFwlNcpKEZUzKDcJWOR1QhwTdndcDYRtOhtR6a6GR1knw+7B4e/kgYEqxNk5YedTPx68Xqkz/6rc= 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: 1b9ba19c-7020-4d38-3cc2-08d735e1947e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2019 11:25:26.9910 (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: CMev1kLYbSZr+2NR1a8HW6WqPh9Aq2zrwfM3MInbe4YIgG9sbcMolihrqmmLngMqiPrLAO7HNw9HQzxOyT7HMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6431 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 Fan, >=20 > Hi Akhil, >=20 > You are right, the new API will process the crypto workload, no heavy enq= ueue > Dequeue operations required. >=20 > Cryptodev tends to support multiple crypto devices, including HW and SW. > The 3-cache line access, iova address computation and assignment, simulat= ion > of async enqueue/dequeue operations, allocate and free crypto ops, even t= he > mbuf linked-list for scatter-gather buffers are too heavy for SW crypto P= MDs. Why cant we have a cryptodev synchronous API which work on plain bufs as yo= ur suggested API and use the same crypto sym_session creation logic as it was before? It= will perform same as it is doing in this series. >=20 > To create this new synchronous API in cryptodev cannot avoid the problem > listed above: first the API shall not serve only to part of the crypto (= SW) PMDs - > as you know, it is Cryptodev. The users can expect some PMD only support = part > of the overall algorithms, but not the workload processing API. Why cant we have an optional data path in cryptodev for synchronous behavio= r if the underlying PMD support it. It depends on the PMD to decide whether it can h= ave it supported or not. Only a feature flag will be needed to decide that. One more option could be a PMD API which the application can directly call = if the mode is only supported in very few PMDs. This could be a backup if there is= a=20 requirement of deprecation notice etc. >=20 > Another reason is, there is assumption made, first when creating a crypto= op > we have to allocate the memory to hold crypto op + sym op + iv, - we cann= ot > simply declare an array of crypto ops in the run-time and discard it when > processing > is done. Also we need to fill aad and digest HW address, which is not req= uired for > SW at all. We are defining a new API which may have its own parameters and requirement= s which Need to be fulfilled. In case it was a rte_security API, then also you are = defining a new way Of packet execution and API params. So it would be same. You can reduce the cache line accesses as you need in the new API. The session logic need not be changed from crypto session to security sessi= on. Only the data patch need to be altered as per the new API. >=20 > Bottom line: using crypto op will still have 3 cache-line access performa= nce > problem. >=20 > So if we to create the new API in Cryptodev instead of rte_security, we n= eed to > create new crypto op structure only for the SW PMDs, carefully document t= hem > to not confuse with existing cryptodev APIs, make new device feature flag= s to > indicate the API is not supported by some PMDs, and again carefully docum= ent > them of these device feature flags. The explanation of the new API will also happen in case it is a security AP= I. Instead you need to add more explanation for session also which is already there in cryptode= v. >=20 > So, to push these changes to rte_security instead the above problem can b= e > resolved, > and the performance improvement because of this change is big for smaller > packets > - I attached a performance test app in the patchset. I believe there wont be any perf gap in case the optimized new cryptodev AP= I is used. >=20 > For rte_security, we already have inline-crypto type that works quite clo= se to the > this > new API, the only difference is that it is processed by the CPU cycles. A= s you may > have already seen the ipsec-library has wrapped these changes, and ipsec-= secgw > has only minimum updates to adopt this change too. So to the end user, if= they > use IPSec this patchset can seamlessly enabled with just commandline upda= te > when > creating an SA. In the IPSec application I do not see the changes wrt the new execution API= . So the data path is not getting handled there. It looks incomplete. The use= r experience to use the new API will definitely be changed. So I believe this patchset is not required in rte_security, we can have it = in cryptodev unless I have missed something. >=20 > Regards, > Fan >=20 >=20 > > -----Original Message----- > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > > Sent: Friday, September 6, 2019 10:01 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 action type= and > > API > > > > > > Hi Fan, > > > > > > Hi Akhil, > > > > > > This action type allows the burst of symmetric crypto workload using > > > the same algorithm, key, and direction being processed by CPU cycles > > synchronously. > > > This flexible action type does not require external hardware > > > involvement, 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_burst an= d > > corresponding dequeue burst. > > It would be a new API something like process_packets and it will have t= he > > crypto processed packets while returning from the API? > > > > I still do not understand why we cannot do with the conventional crypto= lib > > only. > > As far as I can understand, you are not doing any protocol processing o= r any > > value add To the crypto processing. IMO, you just need a synchronous cr= ypto > > processing API which Can be defined in cryptodev, you don't need to re- > > create a crypto session in the name of Security session in the driver j= ust to do > > a synchronous processing. > > > > > > > > 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)_perftest 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 on th= e > > > session data specified and preprocessed in the security session. > > > Different than the inline or lookaside modes, when the function exits= , > > > the user will expect the buffers are either processed successfully, o= r > > > having the error number assigned to the appropriate index of the stat= us > > 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 action > > > > type and API > > > > > > > > Hi Fan, > > > > > > > > > > > > > > This patch introduce new RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > > > > action > > > > > type to security library. The type represents performing crypto > > > > > operation with CPU cycles. The patch also includes a new API to > > > > > process crypto operations in bulk and the function pointers for P= MDs. > > > > > > > > > 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 le= tter. > > > > Also I see that there are new APIs for processing crypto operations= in > > bulk. > > > > What does that mean. How are they different from the existing APIs > > > > which are also handling bulk crypto ops depending on the budget. > > > > > > > > > > > > -Akhil