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 BCFBDA046B for ; Thu, 25 Jul 2019 13:27:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 885441BFB7; Thu, 25 Jul 2019 13:27:34 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20045.outbound.protection.outlook.com [40.107.2.45]) by dpdk.org (Postfix) with ESMTP id 2A1181BF6B for ; Thu, 25 Jul 2019 13:27:33 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AIpI1CzvV/JNt0nrztrBxkleycdoDOo5Pe2wArG/SVcOtgTgGmZXauH3/OkU7cFAxaBRxbiCpI7RqXeU6+LHbUnqY1+bvO+VFbe9d40IfWcCSll6pmwbcKfI6gm5LiQksfwi8PhyQCZSWfNyRmeUEbAhau+Wea0xa3k/4A+vHH+ZGEZvxxxi9GNlJKPHzm3z0clrXrXMe8LU4MBQp2aAmqASrR9+q+IQoDocdoItejle6cLiJgCLOUuKnU/P+uoyafDhIuLEQ30zi3wPtyrdzH1aV0TbxuBX2dpRt4/SUm5AVYRwbZMUIeRL7HWTQ0b7pKtU8C9oVqsRk6Q5Pcd2DA== 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=hEAVTQDU6QaNjJ+B0iHoZbefV++G+0F9yhSOyHuDno4=; b=M/U6784n+88c4v68AIM/apZt2w/JHUauSSH+F3kvwfSy7rNySnH/9UeFjvmaJxd3Q9caAZIPaCpanbwPiINJ9VFnatPbwi8JQOLw5zjwbCcTqH8B2HBoV4zftyeOnbsMjx8mN+J8hMRfVEFZqm+89LCm9KhRFil6yrYELy7rVgP/LNLkyiGVHKblcxaJjnXbXs/xUcnLL95QfgLzCQ3ZlLY2gMvV9Y/uunpqsTwTWDHPQf7H4ONFZCm7Bforj2zspXRUaFiiba75QZo8UVdw2aCGY4uCau8QwbTkhnZnG1lTf/XhJVjPlNIV05vdenESxT0dCZEOi+lckYGJutmsYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nxp.com;dmarc=pass action=none header.from=nxp.com;dkim=pass header.d=nxp.com;arc=none 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=hEAVTQDU6QaNjJ+B0iHoZbefV++G+0F9yhSOyHuDno4=; b=Y+cw6zloTU3vTzZS1vFsSG5/z1q7GT92TuulMUMBQJyham1r6QZfvrp+glQkNvt+gMQw1RPHrzhBBWxru3IKUPajUr3hrv3Tc4MiWi2dkhw8YddILLPnKpKQp98YzAI/uQDnQG6z4oovl0wKs9/pwdVcAZpSzFAbJgiz4td+s6Q= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6527.eurprd04.prod.outlook.com (20.179.233.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.13; Thu, 25 Jul 2019 11:27:32 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::d546:8474:f63a:5d22]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::d546:8474:f63a:5d22%6]) with mapi id 15.20.2094.013; Thu, 25 Jul 2019 11:27:32 +0000 From: Akhil Goyal To: Anoob Joseph , Shally Verma , 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: AQHVQf0Uq6n1MCNYAkafRcdHeP7+s6bZdlWAgAFE6YCAABJ3AIAAFSsAgABPWXA= Date: Thu, 25 Jul 2019 11:27:31 +0000 Message-ID: References: <1563958317-480-1-git-send-email-ayverma@marvell.com> In-Reply-To: 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.0.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d8ce0c57-9439-459b-eb12-08d710f3158e 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:VE1PR04MB6527; x-ms-traffictypediagnostic: VE1PR04MB6527: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(136003)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(305945005)(81166006)(81156014)(7736002)(110136005)(71190400001)(71200400001)(33656002)(4326008)(2906002)(99286004)(8936002)(74316002)(256004)(229853002)(3846002)(476003)(6116002)(478600001)(25786009)(14444005)(102836004)(186003)(54906003)(86362001)(26005)(14454004)(64756008)(66556008)(66446008)(53546011)(446003)(11346002)(66946007)(52536014)(44832011)(6506007)(486006)(9686003)(316002)(561944003)(55016002)(6246003)(8676002)(53936002)(76176011)(66066001)(7696005)(76116006)(5660300002)(66476007)(68736007)(6436002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6527; 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: QfjZvNXsXvaxchUYEOA3iIH2KgyqCmf/4AB+U6lsCyplc5KOFJgDvBkPavG5eNSosIbJLzv/MzAa3FK2w88pMH8BBSGGp60sAvwRF5doaoPt7D1TLK1vBFCtgDySSRErYCevCheBhxuhbz/fe+QhLbd3HCiSvTmqE98tiujtujcWEqQKi0CP8NYVw19yWq35nlQ4LRrDzh5X8iqzUrx5D1Oz+AbFWfGIfkAa9An+NUHWxIgWAhtdfTfE8ZYthkB9TmTPK5+9nfkuhYTyuCW1mepp8V+4AZXe2n9A3gSkSLBUUyB2RIQ5t8LRSSP5QCpmlxJtz5o4uarsSyqcUBFpJLtT1fn7Ji++hSIkfWYjYIj7r+xuPljQyN2+2IGIimNT1HYqTgdSDNyraa/+NrVAE+jJYHkTKy1S2uNspp//07U= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8ce0c57-9439-459b-eb12-08d710f3158e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 11:27:31.9410 (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: VE1PR04MB6527 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 Anoob/Shally > > > > Hi Ayuj, > > > > I believe there are couple of issues with this patch. > > > > Are these experimental APIs? I believe they were made stable this relea= se > > and I'm not sure if it is a right practice to edit an API without depre= cation > > 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. >=20 > [Anoob] In the patch, the edited APIs doesn't have experimental tag. I le= ave it to > Akhil's judgement on this. >=20 The API is experimental. Check the .map file. But these kind of patches cannot go in 1908 release, as we have already tag= ged it for RC2. We need to defer this change for 19.11 release. One more issue that I see in this patch. QAT also uses these APIs, so it sh= all also be modified along with openssl.=09 > > > > 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 pi= peline) > > 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 h= aving > > this feature/limitation would make application more complicated. Also, = since > > one asymmetric session can hold both public & private keys, the implici= t > > assumption would be, the session can be used for multiple kinds of > > operations. This change is in contradiction 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 R= SA > > 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 i= s, 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 s= ame > > effect as sessionless). It will help such PMDs to optimize their sessio= n setup > > time by avoiding unnecessary memcpy of keys buffers. >=20 > [Anoob] Contradiction is in the sense of what is a session. Here we are s= aying > one session can have SIGN & VERIFY, but the lifetime of the session is a= ssumed > to be "short". >=20 > > > > 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 the= re 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 natu= re and > > that they should not modify it. >=20 > [Anoob] The current change could break existing applications. And the com= piler > will not be able to detect it. >=20 > > > > Also, I could have the xform allocated from stack (non const, regular l= ocal > > 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 draft= ed > > 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. >=20 > [Anoob] May or may not be? >=20 > > 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 sess= ion. > > And, same will need to be documented about xform for session-less usage > > as well. >=20 > [Anoob] Can you describe how this is required in session-less? >=20 > > Even there, we would ensure that application do not re-use or modify xf= orm > > and its buffers until dequeue happen. So, practically I see, applicatio= n 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 mov= ing > > same definition on session. So for PMDs which support sessions-based > > implementations ( like ours) , believe it completely make sense to enab= le > > 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 flexib= le > > 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. >=20 > [Anoob] I get your intention on avoiding the memcpys. But the current cha= nges > would make the spec more prone to errors. And if we think we should impro= ve > 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 more cleanly. >=20 > > > > 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 ses= sion > > setup time for PMDs, which doesn't require any manipulation of xform da= ta, > > 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