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 DD2EBA046B for ; Thu, 25 Jul 2019 09:58:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A9B491C29F; Thu, 25 Jul 2019 09:58:14 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 401B81C29D for ; Thu, 25 Jul 2019 09:58:13 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6P7p2Tg023140; Thu, 25 Jul 2019 00:58:12 -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=WX2knh3xrUhEYMGgCQz3jqBnCwBKM/oXMk5xUu0c0Js=; b=k1SNqp218o+oZkZSZo5rh25g7TjQgM9fJiZpGjB0XcaPv7DU65pZXejtKkFj5BkuWFnk UPEqshfHwzPRs2P4jWDSfx564ndbEWZuIHAta2Pq+MobStJ8hnCEjST/KaPNQ3SP2idF F1eUkDfKgizONb6z/1piAMObj4Ak1Kx4OoJ1QuWZxs0/SuxN+174mRy8+hdmkiHxOWF4 N7ffKBv0L8Br9vlcXsF0KgqdMTpNTmSLh48LnbMEBDAxkEBfckgO0rS9wCFYAwMV1t84 83qwQo4b2eMJl8rI0MHE6u5lSNg5YOxRPihjbySNLUOwakGl0/W7Uh9FuaH/8WaFHDyh BA== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2tx62505cu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2019 00:58:12 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 25 Jul 2019 00:58:10 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.56) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 25 Jul 2019 00:58:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EOp3HnDE1eu4eNta2t7x3uxAadnUa3v63HOIMwK1ozg37FdXaRFNlO91OS5arXW0SNNP+zY89xlrWFIMZKfDWwDIiBr4gdUuWbmbLd8e64uPppZy4LzAt0eLdrhnXOydPFJtpO+7vTilNb83cvtv8d+KcVdEPEcwYmCRU7vGy9rN0mIE96ArK+A26d9d7JA5gAtEUQjI21PM9R4jTIg1X3+grihhIHPZ1TkBluPur3xxkSON6mMT7CB9TjTi0vhFo5fY6SxhoKimzgfjaniJJU8Gdlm4Jwu6c7FM958M89GDgk3l7ZS8llQL3f21U1aJPnCwUHF7xeR8lCL8cvEBWQ== 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=WX2knh3xrUhEYMGgCQz3jqBnCwBKM/oXMk5xUu0c0Js=; b=BLO7jfpqh0Pt75s8vLlVcJXmUmneVa31bkxGWfTHxQUlyZbtelGWdTCcjuMc0MGPZNBXOOzygYwHK2o64QVkmHV2ulR5yVHp7HYNh9I2DjgWc0qrOFL4LEnz4kcwAeyzvM4m/ixd8CniPL8Mu0+9c49ZXQuO52htx/0G/TXPdCxMN67wEOSyDIWR7C3LNBWDJ4+a8mLe6ENqmHIvR/VL1sRjeAU8jNxgJcGGO6nAvJwcHDEkwxPcah2JxkUkZPuVV8ezcnsExPKXqj5cqzWK+jptxxE/Mb1lgFwHjXaAQYw3lCELZLRcJDhItx3oEUO79zHleOjkmiNmoRVDzkWzbQ== 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=WX2knh3xrUhEYMGgCQz3jqBnCwBKM/oXMk5xUu0c0Js=; b=l3s+mBzEH9v+0gEL3UIZUpyLl5a3PIwD6mrY1paseikRzuQtogUxbo5Ij5o6V8ub6J3JJ0V9FOhdUElOHEFeYkcmUaOrCZe980OgNxCDOfMRfaEB/eulUeRNUSnl1tyGw+w2FsmxUD/FiJEUP/+/WyolBMchbG0dlwYCo9duZaY= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB1876.namprd18.prod.outlook.com (10.161.154.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Thu, 25 Jul 2019 07:58:08 +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 07:58:08 +0000 From: Shally Verma To: Anoob Joseph , Ayuj Verma , "akhil.goyal@nxp.com" 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: AQHVQf0VE8fh0pVNEkyFNFVWwsyWkqbZdlWAgAFE6YCAAAg8YIAAH2YAgAANVLA= Date: Thu, 25 Jul 2019 07:58:08 +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: 84563abe-c2db-4686-cfdb-08d710d5d50c 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:BN6PR1801MB1876; x-ms-traffictypediagnostic: BN6PR1801MB1876: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(136003)(39860400002)(396003)(199004)(13464003)(189003)(43544003)(5660300002)(81166006)(68736007)(52536014)(9686003)(8936002)(53936002)(6436002)(229853002)(316002)(110136005)(54906003)(2906002)(14444005)(256004)(8676002)(81156014)(64756008)(76116006)(66556008)(66476007)(66446008)(6246003)(66946007)(4326008)(486006)(561944003)(25786009)(14454004)(478600001)(6116002)(3846002)(71200400001)(71190400001)(86362001)(66066001)(446003)(11346002)(76176011)(74316002)(55016002)(7696005)(305945005)(99286004)(33656002)(55236004)(6506007)(102836004)(7736002)(2501003)(53546011)(26005)(186003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB1876; 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: 3Y3W+9wiEMKryda5EZ3D2JqZAOHjAtzAdBl3J/oNjNul1hiakDTP0WS4kZxKqNyyhl2CTPNGFMQIQ0AKT+H/c/YH/FbAl9xBsk4JJMRYZCxVtq2XEd1VCr8+oRaXcaohWVrPL8Pj5Tv0d9m08Jek33bHVn5o7x0K+/TkI6t+TmXOWV2gYVqJu0DaiTdWwlAfFuCcAcQX24NPVp5ZqN+xxkJMwBWYGha8MBXQqqmD0S5kk/wU3MFzIlwqT3no5+rRWmkx8fp2D7Wh9okSPjjtlYWt1MrtwAYTBWxYJejzibTcD6W2TW4uviH9A+cpmlWr2TGuBaHhKVQNIMYH0Rw0FPK/iblcA5U17Tn5gCUuFMKP7JdAZIf65FosjI5ZDp0SQV7whiVYXOUbNYky4rdaVbKJ9MU/hbDjTZYRaNdMt98= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 84563abe-c2db-4686-cfdb-08d710d5d50c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 07:58:08.3370 (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: BN6PR1801MB1876 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" > -----Original Message----- > From: Anoob Joseph > Sent: Thursday, July 25, 2019 12:07 PM > To: Shally Verma ; Ayuj Verma > ; akhil.goyal@nxp.com > 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 Shally, >=20 > Please see inline. >=20 > Thanks, > Anoob >=20 > > -----Original Message----- > > From: Shally Verma > > Sent: Thursday, July 25, 2019 10:52 AM > > To: Anoob Joseph ; Ayuj Verma > > ; akhil.goyal@nxp.com > > 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 > > > > Hi Anoob > > > > Seems your reply is not in plaintext which will make it difficult for > > inline response. So, please take care of that when you reply. > > Rest, please see my response inline. > > > > From: Anoob Joseph > > Sent: Thursday, July 25, 2019 9:46 AM > > To: Ayuj Verma ; akhil.goyal@nxp.com > > Cc: arkadiuszx.kusztal@intel.com; Shally Verma ; > > Sunila Sahu ; Kanaka Durga Kotamarthy > > ; dev@dpdk.org; Fiona Trahe > > > > Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable > > > > 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. >=20 > [Anoob] In the patch, the edited APIs doesn't have experimental tag. I le= ave > it to Akhil's judgement on this. >=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 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 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 optimize their session setup ti= me 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 > assumed to be "short". [Shally] No. we only said, Session will only have keys (which is in xform) = with which SIGN & VERIFY will be performed during enqueue. As long as there're operations to be performed using data set in session, s= ession data should not be manipulated. >=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 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. >=20 > [Anoob] The current change could break existing applications. And the > compiler will not be able to detect it. >=20 [Shally] Application would need to be changed to make sure this criteria is= met. We took care to check same in asym unit test app while proposing chan= ge. > > > > 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. >=20 > [Anoob] May or may not be? >=20 [Shally] Yes. Depending on compiler version type or optimization level. Hav= ent given try to all. > > 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 o= n > session. > > 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 [Shally] We don't know how every PMD might use them. So, it is safe to mark= xform and buffers immutable there too. So this is my thought but I have asked from POC for sessionless, as it is p= roposal by Arek, am yet to get more feedback on that. > > 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. >=20 > [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 wo= uld > suggest not to rush with this change. We can keep the API experimental an= d > continue improving it to fix this issue for all PMDs more cleanly. >=20 [Shally] There's no rush. It is up and open for feedback.=20 This change has an intent to optimize session setup time and since xform da= ta is not supposed to change once it is set on session. Only change proposed is, why not just use app bu= ffers instead of redundant copy of same into PMD buffer. if you see better suggestions , please provide. > > > > 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