From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id B791BA0471 for ; Fri, 21 Jun 2019 16:25:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 089551D533; Fri, 21 Jun 2019 16:25:41 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 66B2D1D532 for ; Fri, 21 Jun 2019 16:25:39 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2019 07:25:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,400,1557212400"; d="scan'208";a="151268529" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga007.jf.intel.com with ESMTP; 21 Jun 2019 07:25:37 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.80]) by IRSMSX109.ger.corp.intel.com ([169.254.13.220]) with mapi id 14.03.0439.000; Fri, 21 Jun 2019 15:18:26 +0100 From: "Trahe, Fiona" To: Akhil Goyal , "Kusztal, ArkadiuszX" , "dev@dpdk.org" , "shally.verma@caviumnetworks.com" CC: "Trahe, Fiona" Thread-Topic: [PATCH] cryptodev: extend api of asymmetric crypto by sessionless Thread-Index: AQHVGkUHWWASMFfof0mYfFRjYZRUS6akoF0AgAF30JD///qlgIAAHWVg Date: Fri, 21 Jun 2019 14:18:25 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B435897A28B6@IRSMSX101.ger.corp.intel.com> References: <20190603194411.8352-1-arkadiuszx.kusztal@intel.com> <348A99DA5F5B7549AA880327E580B435897A26ED@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGZlOTRlZDgtNTg2YS00YTA4LWI0OTctNDg2YTM3MWNkZTZhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOEJxdVFpcGpOZXFYMWlmUmprOGVBWmVqYzg2QnFWVkNnZnBGdVFRNUJVWldxUzR6YnhnRGtETEt2TDR6STFwMyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless 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, > -----Original Message----- > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > Sent: Friday, June 21, 2019 1:23 PM > To: Trahe, Fiona ; Kusztal, ArkadiuszX ; > dev@dpdk.org; shally.verma@caviumnetworks.com > Subject: RE: [PATCH] cryptodev: extend api of asymmetric crypto by sessio= nless >=20 > Hi Fiona, >=20 > > > > Hi Akhil, Arek, Shally, > > > > > -----Original Message----- > > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > > > Sent: Thursday, June 20, 2019 3:17 PM > > > To: Kusztal, ArkadiuszX ; dev@dpdk.org > > > Cc: Trahe, Fiona ; > > shally.verma@caviumnetworks.com > > > Subject: RE: [PATCH] cryptodev: extend api of asymmetric crypto by > > sessionless > > > > > > > > Asymmetric cryptography algorithms may more likely use > > > > sessionless API so there is need to extend API. > > > > > > > > Signed-off-by: Arek Kusztal > > > > --- > > > Acked-by: Akhil Goyal > > > > [Fiona] The code is ok but I think a little more is needed. > > As all PMDs don't support sessionless, this needs to be handled as an o= ptional > > capability. > > And in future some PMDs may only support SESSIONLESS and some only supp= ort > > WITH_SESSION. >=20 >=20 > I believe this holds true for symmetric crypto as well. But adding a feat= ure flag for everything may beat > the purpose > Of adding a feature flag. Sessionless crypto operations in symmetric cryp= to is being used without any > issue for a long > And nobody feel the need of that as of today. So my question is how asymm= etric crypto pmds are > different that they > Need feature flag? >=20 > If the driver does not support sessionless, then it may give an error whi= le creating it. I don't think that is > an issue. It is > Already being handled in the rte_crypto_op by an enum which denote that t= he 'op' need to be > processed with some > Session or with xform. >=20 > > So I propose adding 2 feature flags to the API > > RTE_CRYPTODEV_FF_ASYM_WTH_SESSION > > RTE_CRYPTODEV_FF_ASYM_SESSIONLESS > > and including in this patch the PMD and UT changes to set and test the = first flag. [Fiona] symmetric crypto is inherently session-based, so all PMDs support t= his. I don't know how much real use SESSIONLESS actually gets. For asymmetric, my understanding is that sessionless is more likely to be u= sed. Sequences of ops using the same params/keys are an unlikely use-case, = so there's no advantage to setting up a session and it's an extra API call = so preferable to avoid. That said, I think it would be ok with one feature flag. If a PMD doesn't support WITH_SESSION, the session_init API will fail with= -ENOTSUP, so giving the app the information it needs. This can be document= ed as a PMD limitation and I'm ok with it not having a feature flag. However if a PMD doesn't support SESSIONLESS, then the fail will only occur= on the op_enqueue_burst.=20 Failure to enqueue the next op is a typical outcome on a busy hardware devi= ce, and the app will likely assume the device is busy and try again with sa= me result. The PMD could change the op.status to OP_STATUS_ERROR or OP_INV= ALID_SESSION but it would still require the app to check the status of the = next op which failed to enqueue. I think it better to detect this before th= e op_enqueue by providing a RTE_CRYPTODEV_FF_ASYM_SESSIONLESS feature flag. > > We'll follow up with SESSIONLESS QAT implementation and UTs in a separa= te > > patchset. > > Also documentation updates should go with this API patch, i.e. > > - update section 16.7.2 in the cryptodev programmers guide - and revie= w that > > doc in case other sections need updating. > Yes this needs to be updated if the implementation is complete and we hav= e some PMD supporting > that. [Fiona] Are you saying we need to submit the PMD changes with this API patc= h? Or can we do separately as we'd planned? >=20 > > - fix comment in rte_crypto.h under STATUS_INVALID_SESSION > > - release note > > > > >=20 >=20 > -Akhil