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 28233A2EDB for ; Fri, 6 Sep 2019 15:12:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A8EDD1F35A; Fri, 6 Sep 2019 15:12:38 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 09B391F2BA for ; Fri, 6 Sep 2019 15:12:35 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 06:12:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,473,1559545200"; d="scan'208";a="199516076" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga001.fm.intel.com with ESMTP; 06 Sep 2019 06:12:29 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.129]) by IRSMSX104.ger.corp.intel.com ([169.254.5.103]) with mapi id 14.03.0439.000; Fri, 6 Sep 2019 14:12:28 +0100 From: "Zhang, Roy Fan" To: Akhil Goyal , "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: AQHVYm4YTD6+9RxOHE+pmjY8VoDMaqcbQpEAgAAy7FCAAtgfAIAAS81A Date: Fri, 6 Sep 2019 13:12:27 +0000 Message-ID: <9F7182E3F746AB4EA17801C148F3C604336AF46E@IRSMSX101.ger.corp.intel.com> References: <20190903154046.55992-1-roy.fan.zhang@intel.com> <20190903154046.55992-2-roy.fan.zhang@intel.com> <9F7182E3F746AB4EA17801C148F3C6043369D686@IRSMSX101.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDNiMTVhMWItNjYwOS00YjRjLTkzNzItOWE5MjBlOGQ5YjJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibVl6ZXlYMkRSRFRSOUtYZjZPcWRWdjZ1clA5aStwV3N0Z1BVZktCSjhkVjJPck50ZlVBc0JkSUFCSFdDcThpMCJ9 dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 Akhil, You are right, the new API will process the crypto workload, no heavy enque= ue Dequeue operations required.=20 Cryptodev tends to support multiple crypto devices, including HW and SW.=20 The 3-cache line access, iova address computation and assignment, simulatio= n of async enqueue/dequeue operations, allocate and free crypto ops, even the mbuf linked-list for scatter-gather buffers are too heavy for SW crypto PMD= s. 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 pa= rt of the overall algorithms, but not the workload processing API.=20 Another reason is, there is assumption made, first when creating a crypto o= p we have to allocate the memory to hold crypto op + sym op + iv, - we cannot simply declare an array of crypto ops in the run-time and discard it when p= rocessing is done. Also we need to fill aad and digest HW address, which is not requi= red for SW at all.=20 Bottom line: using crypto op will still have 3 cache-line access performanc= e problem. So if we to create the new API in Cryptodev instead of rte_security, we nee= d to create new crypto op structure only for the SW PMDs, carefully document the= m to not confuse with existing cryptodev APIs, make new device feature flags = to indicate the API is not supported by some PMDs, and again carefully documen= t them of these device feature flags. So, to push these changes to rte_security instead the above problem can be = resolved, and the performance improvement because of this change is big for smaller p= ackets - I attached a performance test app in the patchset. For rte_security, we already have inline-crypto type that works quite close= to the this new API, the only difference is that it is processed by the CPU cycles. As = you may have already seen the ipsec-library has wrapped these changes, and ipsec-se= cgw has only minimum updates to adopt this change too. So to the end user, if t= hey=20 use IPSec this patchset can seamlessly enabled with just commandline update= when creating an SA. Regards, Fan =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 a= nd > API >=20 >=20 > 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. >=20 > Does that mean application will not call the cryptodev_enqueue_burst and > corresponding dequeue burst. > It would be a new API something like process_packets and it will have the > crypto processed packets while returning from the API? >=20 > I still do not understand why we cannot do with the conventional crypto l= ib > only. > As far as I can understand, you are not doing any protocol processing or = any > value add To the crypto processing. IMO, you just need a synchronous cryp= to > 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 jus= t to do > a synchronous processing. >=20 > > > > 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 the > > 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, or > > having the 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 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 PMD= s. > > > > > > > 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 lett= er. > > > Also I see that there are new APIs for processing crypto operations i= n > 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