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 40EBAA046B for ; Mon, 24 Jun 2019 09:05:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 634001BF14; Mon, 24 Jun 2019 09:05:07 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20077.outbound.protection.outlook.com [40.107.2.77]) by dpdk.org (Postfix) with ESMTP id 274AB1BED2 for ; Mon, 24 Jun 2019 09:05:06 +0200 (CEST) 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=ryahdIjyZ/j2nuLirWCuOcVvbKjxD6uhFYD4NU/Z+BU=; b=CM358fW9PpPUPm1d0+SUjnw016uq9WOQrA+svkA+cL8/vuvqXrEO6IUHs3lFI8uZo4M6YCjvr/0+dkyBtW/6rdwl36fIWs9FeNFVzKQEeypiGFbtEE1CnYtZBZlMOP+THLQci9DCq14brbUFkSLX8w72fx/gJtIwGqtfRPLeNJM= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6352.eurprd04.prod.outlook.com (10.255.118.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Mon, 24 Jun 2019 07:05:04 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0%7]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 07:05:04 +0000 From: Akhil Goyal To: "Trahe, Fiona" , "Kusztal, ArkadiuszX" , "dev@dpdk.org" , Shally Verma Thread-Topic: [PATCH] cryptodev: extend api of asymmetric crypto by sessionless Thread-Index: AQHVGkUG0vP5A2eKj0yqcmlq0uC1qKaksP4AgAFr3ICAAAMyUIAAI8qAgAQ3IZA= Date: Mon, 24 Jun 2019 07:05:04 +0000 Message-ID: References: <20190603194411.8352-1-arkadiuszx.kusztal@intel.com> <348A99DA5F5B7549AA880327E580B435897A26ED@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B435897A28B6@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B435897A28B6@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: 65af6065-34fc-40d4-a51e-08d6f8724898 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6352; x-ms-traffictypediagnostic: VE1PR04MB6352: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(376002)(366004)(39860400002)(13464003)(189003)(199004)(6246003)(102836004)(14454004)(5660300002)(476003)(71200400001)(66946007)(71190400001)(53936002)(7696005)(186003)(229853002)(316002)(7736002)(11346002)(446003)(486006)(64756008)(66476007)(8936002)(66446008)(53546011)(25786009)(6436002)(66556008)(86362001)(256004)(73956011)(81156014)(76176011)(8676002)(76116006)(9686003)(81166006)(6506007)(99286004)(55016002)(14444005)(2501003)(26005)(305945005)(66066001)(3846002)(44832011)(33656002)(110136005)(2906002)(68736007)(478600001)(74316002)(52536014)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6352; 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: 3gAX2+d1oT95yRVV8lM7ynAHnQ0f93/eL7rtM7FBX6wMf6VcOk5T1jP4e/6gy3hPd5HzAic5ofjON1YQhpsUWL5hHGzMw/pg2yPPlGCShjvvsuOs1mq2JOcud9QtYbbuGoPD6laAMfshrVz4UDfk36aywy0YMoEmrSWdvFUKEYLe88RO5xnBO8z1Hpmen2Uz7S645cq4LNDEoVlUK8Pg/gSeq4UejOqo1S+j6NcA97/fxN0qkIjMleB1t939iy2qzAD+BtPB+nkvbNkZmqnHvknPZwR6auLcbKNsP8RxOwU4FloLtKLc1Ezew+APavKHIiVmGqUPC6lkq9KYN7ozoJvWwf+WqJ8zmGh1xiEs+2gX1FnMLHyF/7Q5vHD0yGeKo4/LZIcXpHlLe4vGKPE0tG1HjDiHu39X3zJfobA0tLU= 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: 65af6065-34fc-40d4-a51e-08d6f8724898 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 07:05:04.5658 (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: akhil.goyal@nxp.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6352 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 Fiona >=20 > Hi Akhil, >=20 > > -----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 > sessionless > > > > Hi Fiona, > > > > > > > > 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.or= g > > > > 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 > optional > > > capability. > > > And in future some PMDs may only support SESSIONLESS and some only > support > > > WITH_SESSION. > > > > > > I believe this holds true for symmetric crypto as well. But adding a fe= ature flag > for everything may beat > > the purpose > > Of adding a feature flag. Sessionless crypto operations in symmetric cr= ypto is > being used without any > > issue for a long > > And nobody feel the need of that as of today. So my question is how > asymmetric crypto pmds are > > different that they > > Need feature flag? > > > > If the driver does not support sessionless, then it may give an error w= hile > 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= the > 'op' need to be > > processed with some > > Session or with xform. > > > > > 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 th= e first > flag. > [Fiona] symmetric crypto is inherently session-based, so all PMDs support= this. I > don't know how much real use SESSIONLESS actually gets. > For asymmetric, my understanding is that sessionless is more likely to be= used. > 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 s= o > preferable to avoid. Agreed, if Asymmetric is not likely to have sessions, it should not call th= at API. > 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 wi= th - > 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 occ= ur on > the op_enqueue_burst. Yes on the first enqueue, before actually submitting to the hardware, in th= e driver itself Before sending the request to hardware and return OP_INVALID_SESSION. > Failure to enqueue the next op is a typical outcome on a busy hardware de= vice, > and the app will likely assume the device is busy and try again with same= result. The PMD will not be sending the request to hardware if sessionless is not s= upported. And app will not enqueue the op again if the previous error is OP_INVALID_S= ESSION. > The PMD could change the op.status to OP_STATUS_ERROR or > OP_INVALID_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 = the > op_enqueue by providing a RTE_CRYPTODEV_FF_ASYM_SESSIONLESS feature > flag. On second thought, we can have another value in the enum(op->status) to say= sessionless Is not supported if OP_INVALID_SESSION looks ambiguous instead of setting a= feature flag=20 and making each driver set it if it support sessionless or not. I believe that would be simple and will not bother the data path or the bus= y hardware. Anyways in case of sessions also in sym, we make session on arrival of 1st = packet. That same logic Can be applied here also. I don't think that will be an issue. >=20 >=20 > > > We'll follow up with SESSIONLESS QAT implementation and UTs in a sepa= rate > > > patchset. > > > Also documentation updates should go with this API patch, i.e. > > > - update section 16.7.2 in the cryptodev programmers guide - and rev= iew > that > > > doc in case other sections need updating. > > Yes this needs to be updated if the implementation is complete and we h= ave > some PMD supporting > > that. > [Fiona] Are you saying we need to submit the PMD changes with this API pa= tch? > Or can we do > separately as we'd planned? I believe you should update the documentation when some PMD support session= less. I think we should hold back this patch, until you have a sample PMD/app rea= dy for reference. You may end up adding a few more updates to the lib while actually supporti= ng the functionality. >=20 > > > > > - fix comment in rte_crypto.h under STATUS_INVALID_SESSION > > > - release note > > > > > > > > > > > > -Akhil