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 C50BFA2EDB for ; Fri, 6 Sep 2019 15:27:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 88AA71F369; Fri, 6 Sep 2019 15:27:12 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id AF1DF91 for ; Fri, 6 Sep 2019 15:27:10 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 06:27:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,473,1559545200"; d="scan'208";a="185783646" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 06 Sep 2019 06:27:08 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.73]) by IRSMSX102.ger.corp.intel.com ([169.254.2.160]) with mapi id 14.03.0439.000; Fri, 6 Sep 2019 14:27:08 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , "dev@dpdk.org" CC: "Zhang, Roy Fan" , "Doherty, Declan" , "De Lara Guarch, Pablo" Thread-Topic: [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Thread-Index: AQHVYm4Y+AedzaNgY0qWMAmu5GwNVqcbQpEAgAArCICAAuADAIAARA4A Date: Fri, 6 Sep 2019 13:27:07 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191926A17@irsmsx105.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-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjI0N2ZjYTYtNDU3NC00ODE0LWE2ODYtY2NjZjQ4MDUxNGJmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiemh5aExEbGFBVGNLSCtZUTkzMkdZTlhPNXFrMXlVZmNtclRQQVUycWZEc2RCQ01mWkNSZmZOTkZnRjN0Qk5jcSJ9 x-ctpclassification: CTP_NT 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, > > This action type allows the burst of symmetric crypto workload using th= e same > > algorithm, key, and direction being processed by CPU cycles synchronous= ly. > > This flexible action type does not require external hardware involvemen= t, > > having the crypto workload processed synchronously, and is more perform= ant > > 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. Yes, instead it just call rte_security_process_cpu_crypto_bulk(...) > It would be a new API something like process_packets and it will have the= crypto processed packets while returning from the API? Yes, though the plan is that API will operate on raw data buffers, not mbuf= s. >=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 crypto process= ing 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 just to do a synchronous processing. I suppose your question is why not to have rte_crypot_process_cpu_crypto_bu= lk(...) instead? The main reason is that would require disruptive changes in existing crypto= dev API (would cause ABI/API breakage). Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO need some extra informatio= n that normal crypto_sym_xform doesn't contain=20 (cipher offset from the start of the buffer, might be something extra in fu= ture). Also right now there is no way to add new type of crypto_sym_session withou= t either breaking existing crypto-dev ABI/API or introducing new structure=20 (rte_crypto_sym_cpu_session or so) for that. =20 While rte_security is designed in a way that we can add new session types a= nd related parameters without causing API/ABI breakage.=20 BTW, what is your concern with proposed approach (via rte_security)? >From my perspective it is a lightweight change and it is totally optional for the crypto PMDs to support it or not. Konstantin=20 > > > > AESNI-GCM and AESNI-MB PMDs are updated with this support. There is a s= mall > > 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 w= ill > > expect the buffers are either processed successfully, or having the err= or 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, Decl= an > > > ; De Lara Guarch, Pablo > > > > > > Subject: RE: [RFC PATCH 1/9] security: introduce CPU Crypto action ty= pe 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. Coul= d you > > > please elaborate the flow in the documentation. If not in documentati= on > > > right now, then please elaborate the flow in cover letter. > > > 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 wh= ich > > > are also handling bulk crypto ops depending on the budget. > > > > > > > > > -Akhil