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 B3AC2A046B for ; Thu, 25 Jul 2019 08:37:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4E8771C274; Thu, 25 Jul 2019 08:37:38 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 92E0D1C26D for ; Thu, 25 Jul 2019 08:37:35 +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 x6P6ZVKx006946; Wed, 24 Jul 2019 23:37:34 -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=zGE8LqjO/k/rjz42pqkZIJN4VAdygRLMV73q77Rut6U=; b=MehFU5DVIgFVGfKZOFfVbfTQBZFIyh86nN4426Sg0CzuR6BdX2s+6JiZnVa0U/rdIA5S ABUI2yGP4b66/nXcUMppgWpd+TUA0Z7BSjJNGTfbGHcgtA5ZkENWr8dSSVQx/RWd0NjA 7ex8Cvo5xgupDUY/OvvLAAsZY7PPbaN93hIvVIkx/GEexNsf8jQx3l9U5VADNJuHjCvs RLGfTnTPUc8+jffYMNqB1WI2oe/wbaDvyvXqZEicunGyOCq4W7S1pewtjYwFVjRlNVIk CCdWgF5Iy68CyGQhqcEFsgsZWozULEGl6R1vA7e0rFcHzMHZole49n68d9FiJgUKEcVN tQ== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0a-0016f401.pphosted.com with ESMTP id 2tx61rg80m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 23:37:34 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 24 Jul 2019 23:37:33 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.51) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 24 Jul 2019 23:37:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Flvn3JA1cNFglB4QLrj4g/qao2wnXhnqH2tOUJ/v7yT2VBHFPiRSMK/jUPzGusOyPtzK8fFn6ypvz+NOLTUoCMBWJaH9l7GliA6IEGYOtPbxGLZSAK0OVcDWdoNsXzh6Dh+J8r5dJD0+AQ6i8evS4UnMnpnXHg+m5snh4rE5d9HUskS4rHn7Wd1Llo0g0D2XRhuipx294ZooKK7af6RK6COP1CZNuJB+PzQNF3CDwEuQ99CD+UpHkGi6LX0LLsXrf6AIqyCk1sDU2acokfIYaebg47yafVSeUd6k/Mmik0NwJUo2esgiuVqJbdJcscyOYFKS+9AcM2muLy1tOdRRdA== 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=zGE8LqjO/k/rjz42pqkZIJN4VAdygRLMV73q77Rut6U=; b=oFiVXylEQiYTJxThXqABf9dF2UfgTfWsHbRdyJNBKXF8jPhpWlUgbZm74YT8rZhfetcOurpcN2XoL8e3Q5IZQp3hXPtcxLh4stgLw8EpLwjEgOSTqPgER/SnQ76ge4s0grAIFf4cf3uhF+5XoPYwoX8exSOg67+bVUY77h7Z3TYIVsMx1A3R5iV06ljDOFbER9wsKF0e2Yoj0A2r3f2ABeNwk5mktiqbJ1YUUFd+klPZz9ePgj8nwLLmDFaCRe8x9yzSazU1sLYBHxCDL6WbjbBBROdAtv0gFFTGm0tHMlDtSdPrRcbO+qWn2tlBe/TO511DmS+1WemFI6j5ivV8fg== 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=zGE8LqjO/k/rjz42pqkZIJN4VAdygRLMV73q77Rut6U=; b=X+bcln901fnWR2opa2GeJeJS6o7dlrbifTEpoybM624PtsryUMaNxWZ1ZqQhman3w3vfHGAN1wlQdLskZiZTvDK5GQdMdDClggDva1z0vhLLGKq5/Idt6AWViUm5SHpSYsUavG5WsUz2opEqUsRPe6ugdbXdR1ogfPLTk+L8Da8= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2702.namprd18.prod.outlook.com (20.178.255.138) 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 06:37:28 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5102:f98d:84c4:a71e]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5102:f98d:84c4:a71e%5]) with mapi id 15.20.2115.005; Thu, 25 Jul 2019 06:37:28 +0000 From: Anoob Joseph To: Shally Verma , 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: AQHVQf0VPcdF0o1ybE6M5aW83PjvgqbZdlWAgAE1vvCAACGiAIAAERlQ Date: Thu, 25 Jul 2019 06:37:28 +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: x-originating-ip: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bb283c7-998f-4d5d-bb13-08d710ca9050 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:MN2PR18MB2702; x-ms-traffictypediagnostic: MN2PR18MB2702: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0109D382B0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(376002)(396003)(366004)(136003)(199004)(189003)(13464003)(43544003)(99286004)(11346002)(561944003)(68736007)(256004)(54906003)(305945005)(8936002)(6116002)(14444005)(74316002)(33656002)(71190400001)(81166006)(7736002)(86362001)(446003)(476003)(53546011)(6246003)(26005)(3846002)(316002)(66066001)(71200400001)(81156014)(2501003)(8676002)(66476007)(186003)(110136005)(2906002)(64756008)(66556008)(6506007)(66946007)(478600001)(55016002)(102836004)(9686003)(66446008)(486006)(55236004)(229853002)(52536014)(6436002)(76116006)(14454004)(76176011)(4326008)(53936002)(7696005)(25786009)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2702; H:MN2PR18MB2877.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: jBWX552NDp8e19UbfbSFsEpE1rVKM2shTPjC9hLj0PQR4sbHQkoh5Aio33JzrphQh6zlnLjiXaftHSLVDIjKxxwN73mO3seut87fddyhOTaYkrnJbW5khjHxgPYt2FTb0336UglKHUnxRiadhlyGVkqDTk3YXAupQm2JHGH8lRG48JswwK71RzkIBC5cU/epRiY6B8obttO699bFat1luN4BCNc+DqPk/XbbnPh8NmfHLxN7OAiKix6/i4wM+ttOiQcXmivDpd3hl6JKdRGh7Cgnv4CS43HVh0Jit17O3oJFyJF3YWJrIoTadzqzhws+VGuVnWD0/5dAquHhLKw+LU06n+qmD/Z5SAWH95j5gajWiPB+vTx8Bfj6ADx8N8rNE7jucoZrLB9EbWV1/aGxQnyuwXHfi4Sxeg3MO0A7piA= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7bb283c7-998f-4d5d-bb13-08d710ca9050 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 06:37:28.4853 (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: anoobj@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2702 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-25_03: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 Shally, Please see inline. Thanks, Anoob > -----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 >=20 > Hi Anoob >=20 > Seems your reply is not in plaintext which will make it difficult for inl= ine > response. So, please take care of that when you reply. > Rest, please see my response inline. >=20 > 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 >=20 > Hi Ayuj, >=20 > I believe there are couple of issues with this patch. >=20 > 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 depreca= tion > 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 leav= e it to Akhil's judgement on this. =20 >=20 > I think, the approach here is wrong. If the lifetime of the session is ex= pected > to be only few packets, then session-less (which I believe is in the pipe= line) > would make more sense. > [Shally] See my response further below on this. >=20 > If the lifetime of the session is expected to be more than that, then hav= ing > this feature/limitation would make application more complicated. Also, si= nce > 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 f= rom > 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 d= on'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 sam= e > effect as sessionless). It will help such PMDs to optimize 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 say= ing one session can have SIGN & VERIFY, but the lifetime of the session is= assumed to be "short".=20 >=20 > But my major concern is how this can lead to accidental errors. Making th= e > 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 co= nst > 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, in= tention > 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 compi= ler will not be able to detect it. =20 >=20 > Also, I could have the xform allocated from stack (non const, regular loc= al > variable) and then call the session_init. Would compiler throw an issue i= n that > case? I doubt so. >=20 > void abc(const int t) > { > =A0=A0=A0=A0=A0=A0=A0 printf("%d\n", t); > } >=20 > 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); > } >=20 > To summarize, if this assumption is accepted, then compiler will not be a= ble > 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-le= ss, > 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 sessio= n. > 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? =20 > Even there, we would ensure that application do not re-use or modify xfor= m > and its buffers until dequeue happen. So, practically I see, application = would > have to take of these cases in session-less as well. >=20 > Since in session-based case, xform are set on it than ops, so we're movin= g > 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 chang= es would make the spec more prone to errors. And if we think we should impr= ove the key handling done in both session & session-less, I would suggest n= ot 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 >=20 > So this change is NACK from my side. >=20 > Thanks, > Anoob >=20 > 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 >=20 > +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 >=20 > Mark asym xform as immutable till lifetime of session. It will save sessi= on > setup time for PMDs, which doesn't require any manipulation of xform data= , > by directly using these buffers. >=20 > * Updated xform type in session init/configure > =A0 API as constant. > * Updated doc with proper transform description. > * Updated openssl PMD with above changes. >=20 > Ayuj Verma (2): > =A0 lib/crypto: declare crypto asym xform immutable > =A0 crypto/openssl: mark asym xform constant >=20 > =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(-) >=20 > -- > 1.8.3.1