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 BA49AA046B for ; Thu, 25 Jul 2019 13:35:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1D5C91C306; Thu, 25 Jul 2019 13:35:25 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id EF89D1C2FE for ; Thu, 25 Jul 2019 13:35:22 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6PBZLPU016854; Thu, 25 Jul 2019 04:35:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=6sWbmw2mkrysUr4jufopQdT6Vp+eRxJvkrWS4ydx2tU=; b=UrPedWol12yC/pJq2QkyAWCItge+8XxgNaawIAt33OkQZ0ExG+FAOprCsM+C3WCNfILp RNfCHy29qiAbQCHWancr4JGl2QXp5LVeydk9KXerdBe+LKe9+GA+onu2FQa3yxEMbDe4 05oVwZeiorELW2Ap3eVCgWUJMbMn1Am2UhkkZ09DxQM5h+t3mx4laEVxkAhEQweMtJcF /Pui7L9mh7ou2sQfirGLk11tCufNdqZr3NynOCNiYziedK176LWKK7QUQm1q8cS+K4Kd fDrV8a316/eYnnyW5fKfDOf1exHoDrAOITpdXU0Mm6agyNN2+eWmxUD+y3uU9riECs6t sw== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2tx61rh8m7-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2019 04:35:21 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 25 Jul 2019 04:35:16 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.54) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 25 Jul 2019 04:35:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IZXirRlTEPuJsjRGrYcb5eougSLFyDVQ3hvtZ9a0jnn7QK4bON8umzmRlp9ngqm8KedtM+xJNJlC6hlVXbXTUl2OA+aiS2l8TMkhSqx+cQPqtelYUJbLtvnv9dlzHSu1TAcbWYHA3BGZWiGhVG5khKRwj8cFYl7JC7uYjcEslpfhr9wttVFhkeoas0xg99M2MXoJ1aieyGMPVrSFQuZLQuOtz81zFhIdsCJM6jWkv7ghmFXC9Oc2aFQ1QxIPwssCM8YZ/BW1X+kxKap0Fuq79ouR7cFFSIU+nxTF8YI1jOnp6J6OLZkZF1thg1dU3h0vJp4fxVJD21Y+n0FfhePGqQ== 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=6sWbmw2mkrysUr4jufopQdT6Vp+eRxJvkrWS4ydx2tU=; b=cVbeVKw5Sh4V3P3VlPsA6M8UOSfZr48/9W53DGbnN4Kzhw0/M63TZH9iPALP9Fc1mjVZB9zhpV4S3XdGsUpR8o2/WYXG5z8mc9q0jy+mDW9KgOnmDWDHYZraARCj3HxOmyfaEE4v77KmI8nroxrnjIbhk2B1WjwI291T1wF0wjDBDh2xWNUBcqJnwcudq652jVnhh/beZh48XKveZy3b1c1VInXNXj8DWtDUUCdSnscqq+fXIyTS1N4DFfA/7OzQRfnFbNxmuGjHiDt0GWldbKdJ/OgKXhXJEDwRwJluPw6krvlKrCd6pO69wIAew30S+4cnRV4zBRDMCXkvvE4QWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6sWbmw2mkrysUr4jufopQdT6Vp+eRxJvkrWS4ydx2tU=; b=SNX4+TT2Pfe9L48QAMsC1f6zpziF7zndomtslDgDRXP2N+Ln2oDh6HebtVYyBEHjNs5c/7RDL7uNI1yVRy6l7m3LE1T5MlSAgqM+Ui63xUrmpVf+02Ab2TCmOdOhtPSzrHHOj+xaeshjRS0zD1jI0eB2o/EDE+/Nia1uBM22MFU= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB2067.namprd18.prod.outlook.com (10.161.156.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Thu, 25 Jul 2019 11:35:14 +0000 Received: from BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b9c4:1fd1:a47e:cd72]) by BN6PR1801MB2052.namprd18.prod.outlook.com ([fe80::b9c4:1fd1:a47e:cd72%6]) with mapi id 15.20.2094.017; Thu, 25 Jul 2019 11:35:14 +0000 From: Shally Verma To: Akhil Goyal , Anoob Joseph , "Ayuj Verma" CC: "arkadiuszx.kusztal@intel.com" , Sunila Sahu , Kanaka Durga Kotamarthy , "dev@dpdk.org" , Fiona Trahe Thread-Topic: [PATCH v1 0/2] declare crypto asym xform immutable Thread-Index: AQHVQf0VE8fh0pVNEkyFNFVWwsyWkqbZdlWAgAFE6YCAAAg8YIAAH2YAgABRCoCAAAFPoA== Date: Thu, 25 Jul 2019 11:35:13 +0000 Message-ID: References: <1563958317-480-1-git-send-email-ayverma@marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e45008ea-65b4-48c6-cb50-08d710f428ec x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR1801MB2067; x-ms-traffictypediagnostic: BN6PR1801MB2067: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(39860400002)(396003)(366004)(199004)(189003)(13464003)(54906003)(86362001)(5660300002)(25786009)(76116006)(81156014)(8936002)(81166006)(52536014)(68736007)(110136005)(478600001)(76176011)(33656002)(316002)(7696005)(66066001)(561944003)(66556008)(66476007)(102836004)(64756008)(66446008)(53936002)(55236004)(2906002)(26005)(6436002)(99286004)(8676002)(66946007)(6506007)(6116002)(305945005)(6246003)(7736002)(186003)(446003)(71190400001)(14454004)(55016002)(53546011)(74316002)(256004)(9686003)(486006)(14444005)(476003)(11346002)(229853002)(4326008)(3846002)(6636002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB2067; H:BN6PR1801MB2052.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /nTR6LxhaetcZaYBH4KARB014EsT8Kdntg4+83ETfg7QvWiMwKdvCiJPcSjDdLnZhdDix0IUCBPOdVbhpHnryOlfm4FkYqYsAfON+rTBCXcg3g1sPELTA+KjhcX3cbWzr0nnW2neUkR5slClBwmxxwFnNnongBHa8MIY2Z7a0FnJ5Pu8F53pdyVBApz9Uhhoc9DfDWDlC7a4K4Jox1INqEDM8tKIeXtV29tG+O9tB4h+A0qcZQBWjNp0UPiCLyT+grAr0SrPTkuyZJAOfoUeVGvO/HYhB8dSTZIg9DQ2LLbM92ChGtjIxOSVM71mgIvdo1rB1Jft6/wDsVsPMurM2sOcyVFpa/vVzdZJcPniSxmIf8iXlE1IDGHtYoYm2boJa1w3lJkTZsWDkLlZQqV7s3zC66Tw1FbEInEO9bUBkLs= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e45008ea-65b4-48c6-cb50-08d710f428ec X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 11:35:13.8947 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: shallyv@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1801MB2067 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-25_04:2019-07-25,2019-07-25 signatures=0 Subject: Re: [dpdk-dev] [PATCH v1 0/2] declare crypto asym xform immutable 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 > Sent: Thursday, July 25, 2019 4:58 PM > To: Anoob Joseph ; Shally Verma > ; Ayuj Verma > Cc: arkadiuszx.kusztal@intel.com; Sunila Sahu ; Kanaka > Durga Kotamarthy ; dev@dpdk.org; Fiona > Trahe > Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable >=20 > Hi Anoob/Shally >=20 > > > > > > Hi Ayuj, > > > > > > I believe there are couple of issues with this patch. > > > > > > Are these experimental APIs? I believe they were made stable this > > > release and I'm not sure if it is a right practice to edit an API > > > without deprecation notice after it is made stable. Especially now > > > that RC2 is done. @Akhil, what is your take on this? > > > [Shally] These are experimental still, hence no deprecation notice. > > > We checked about it with Fiona, Akhil before. > > > > [Anoob] In the patch, the edited APIs doesn't have experimental tag. I > > leave it to Akhil's judgement on this. > > > The API is experimental. Check the .map file. >=20 > But these kind of patches cannot go in 1908 release, as we have already > tagged it for RC2. > We need to defer this change for 19.11 release. >=20 [Shally] Well. Cant do anything if we have missed deadline here. Right now = its up for feedback. Meanwhile if we get any agreement and window gets open for nearest release,= then please consider it. > One more issue that I see in this patch. QAT also uses these APIs, so it = shall > also be modified along with openssl. >=20 [Shally] We assume QAT changes will be done by QAT maintainer, once they re= view and approve this change. Thanks Shally >=20 > > > > > > I think, the approach here is wrong. If the lifetime of the session > > > is expected to be only few packets, then session-less (which I > > > believe is in the pipeline) would make more sense. > > > [Shally] See my response further below on this. > > > > > > If the lifetime of the session is expected to be more than that, > > > then having this feature/limitation would make application more > > > complicated. Also, since one asymmetric session can hold both public > > > & private keys, the implicit assumption would be, the session can be > > > used for multiple kinds of operations. This change is in contradictio= n with > that. > > > [Shally] Why the contradiction here? There's no change in session > > > usage from current version. Currently too, once keys are set on > > > asymmetric session, they are used with multiple operations using > > > that sessions, example - once RSA xform is set with keys, then one > > > can perform sign/verify/enc/dec. So, I don't see any change in that > > > notion with this proposal. All we are changing is, PMD which does > > > not need to store keys in specific format (like openssl PMD), can > > > just hold app buffer pointer till session-lifetime (eventually > > > giving same effect as sessionless). It will help such PMDs to optimiz= e their > session setup time by avoiding unnecessary memcpy of keys buffers. > > > > [Anoob] Contradiction is in the sense of what is a session. Here we > > are saying one session can have SIGN & VERIFY, but the lifetime of > > the session is assumed to be "short". > > > > > > > > But my major concern is how this can lead to accidental errors. > > > Making the argument as const will mean the API won't edit its > > > contents. But if there is a pointer in that (key happens to be a > > > pointer inside the xform), having const for xform will not help. > > > This is my understanding. Please correct me if I'm wrong. > > > [Shally] This spec says " xform and its buffers remain constant" . > > > So, intention is to state to apps that buffer passed to xform should > > > be const in nature and that they should not modify it. > > > > [Anoob] The current change could break existing applications. And the > > compiler will not be able to detect it. > > > > > > > > Also, I could have the xform allocated from stack (non const, > > > regular local > > > variable) and then call the session_init. Would compiler throw an > > > issue in that case? I doubt so. > > > > > > void abc(const int t) > > > { > > > =A0=A0=A0=A0=A0=A0=A0 printf("%d\n", t); > > > } > > > > > > void main() > > > { > > > =A0=A0=A0=A0=A0=A0=A0 int t =3D 0; > > > =A0=A0=A0=A0=A0=A0=A0 abc(t); > > > =A0=A0=A0=A0=A0=A0=A0 t =3D 2; > > > =A0=A0=A0=A0=A0=A0=A0 abc(t); > > > } > > > > > > To summarize, if this assumption is accepted, then compiler will not > > > be able to ensure it. And to properly use it, application will have > > > to be drafted differently. And when similar effect can be achieved > > > by having session-less, this seems redundant. > > > [Shally] Compiler may or may not warn on typecast error here. > > > > [Anoob] May or may not be? > > > > > That's why > > > spec and documentation are put in place to ensure that application > > > don't reuse them or destroy them once "xform and its buffers" are set= on > session. > > > And, same will need to be documented about xform for session-less > > > usage as well. > > > > [Anoob] Can you describe how this is required in session-less? > > > > > Even there, we would ensure that application do not re-use or modify > > > xform and its buffers until dequeue happen. So, practically I see, > > > application would have to take of these cases in session-less as well= . > > > > > > Since in session-based case, xform are set on it than ops, so we're > > > moving same definition on session. So for PMDs which support > > > sessions-based implementations ( like ours) , believe it completely > > > make sense to enable sessions to have sessionless effect. If we > > > don't change spec to enable optimization, then we're making > > > 1-approach slower than other. PMDs can adopt any approach more > > > suitable to them. But spec could be made flexible to allow them to > > > experiment with both approaches for performance. Else , PMDs will be > > > forced to experiment around sessionless which may be eventually be an > unnecessary overhead for them. > > > > [Anoob] I get your intention on avoiding the memcpys. But the current > > changes would make the spec more prone to errors. And if we think we > > should improve the key handling done in both session & session-less, I > > would suggest not to rush with this change. We can keep the API > > experimental and continue improving it to fix this issue for all PMDs m= ore > cleanly. > > > > > > > > Thanks > > > Shally > > > > > > So this change is NACK from my side. > > > > > > Thanks, > > > Anoob > > > > > > From: Ayuj Verma > > > Sent: Wednesday, July 24, 2019 2:23 PM > > > To: mailto:akhil.goyal@nxp.com > > > Cc: mailto:arkadiuszx.kusztal@intel.com; Shally Verma > > > ; Sunila Sahu > > > ; Kanaka Durga Kotamarthy > > > ; Anoob Joseph > > > ; mailto:dev@dpdk.org; Fiona Trahe > > > > > > Subject: Re: [PATCH v1 0/2] declare crypto asym xform immutable > > > > > > +Fiona. > > > ________________________________________ > > > From: Ayuj Verma > > > Sent: 24 July 2019 14:21:55 > > > To: mailto:akhil.goyal@nxp.com > > > Cc: mailto:arkadiuszx.kusztal@intel.com > > > ; Shally Verma > > > ; Sunila Sahu > > > ; Kanaka Durga Kotamarthy > > > ; Anoob Joseph > > > ; mailto:dev@dpdk.org > > > ; Ayuj Verma > > > Subject: [PATCH v1 0/2] declare crypto asym xform immutable > > > > > > Mark asym xform as immutable till lifetime of session. It will save > > > session setup time for PMDs, which doesn't require any manipulation > > > of xform data, by directly using these buffers. > > > > > > * Updated xform type in session init/configure > > > =A0 API as constant. > > > * Updated doc with proper transform description. > > > * Updated openssl PMD with above changes. > > > > > > Ayuj Verma (2): > > > =A0 lib/crypto: declare crypto asym xform immutable > > > =A0 crypto/openssl: mark asym xform constant > > > > > > =A0doc/guides/prog_guide/cryptodev_lib.rst=A0=A0=A0=A0=A0 | 10 ++++++= ++++ > > > =A0drivers/crypto/openssl/rte_openssl_pmd_ops.c |=A0 8 ++++---- > > > =A0lib/librte_cryptodev/rte_cryptodev.c=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = 2 +- > > > =A0lib/librte_cryptodev/rte_cryptodev.h=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 = 2 +- > > > =A0lib/librte_cryptodev/rte_cryptodev_pmd.h=A0=A0=A0=A0 |=A0 2 +- > > > =A05 files changed, 17 insertions(+), 7 deletions(-) > > > > > > -- > > > 1.8.3.1