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 48E99A046B for ; Thu, 25 Jul 2019 07:26:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6F1DB1C1FA; Thu, 25 Jul 2019 07:26:16 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 81F941C133 for ; Thu, 25 Jul 2019 07:26:14 +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 x6P5PDDw007892; Wed, 24 Jul 2019 22:26:13 -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=TrXPStxZ6I79OWZ5qkgLPnAEaDwG4pQaoqTlFeMVzpA=; b=HibKqT2YhEO5ISFrwsoFhcWt2FK1jUYemA6w93nPRioXkomfujGfONA5ijQxGLW8WURF K37njIM6jbpr6/bv84gyI/xSBTyIVj8ZHI7JJs8p4YDhlKsbt2P4nGR92ZzMFwrkOH8d j7a2CToNHcdoBsvKtto8Eqp4S46EKwwjxudqWyWtHLU3AZVEzwCjt2UqQEc2/gjQMavd pYNxa2lgHnRZZqn6srmjCUfppXYivCVAQIoG0N4EplQjwm2Vrt54tE2rdYRhHeGJHhsh PNxH/QTqjgQ4ZcG9JvJIh6EKu2CjeHo7ZNdwuvPWMx3ZGtUP9MVZLCl3hw3AmvpA70i4 sQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2tx624ymn9-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 22:26:13 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 24 Jul 2019 22:26:12 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.58) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 24 Jul 2019 22:26:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a1CJmeCx6c63r8aGMpj2taRH0Bmp/huYy48+gdrfWOEsUil1HGeaF+q46yNlgS4PIJhdYH26XF1lfn6/VMFVckGWipuVaAP3VpGV3BaDHEkBOi9cct1eFyyf+Bp3BcnG0pXlEnhficeiNNSjbZG/jKQuMhNObi3tcKBo0KBSheTGjtMRujQdsCAm7OSkQ/XhyDi4+9PMZ+v4WxJsoNMDVFe8oLf/TMtlYmldBk1swpzVQUhYidKyQaD2p5a6yDJuVu17s1IFPjEa9GFGDclHtZ829kSFdW+fepFzEY54Y75PI384y2uwfteDCe4UKeo6j8aSdcrSMFfdO1wpFdfA+Q== 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=TrXPStxZ6I79OWZ5qkgLPnAEaDwG4pQaoqTlFeMVzpA=; b=m1WD4Z3JG/Kk1lhoXG4pkRhwrZohfvIAQ/+3b/xzh3l88pj/4/reJoOpmlQj9DFrmDW7cd0ipEaNVkmBM/PAW8MNCAwLdiL53moQxwQNIJWAH9t4Z28BLCWpisWfW8sGR3n5PHI+tNvMHePMi+2hi0nT3E1KFQHcaMWJXvYH5txFsriFe1ByApLS+vyoIlR0hqGPnF9KiGE0Scoiy7kb6CWYKIxVkM5wXsgtaxw7fQHDcAfTTsT/H1RF8dfpBMpVg1+5zO4vv43FcehQJX98izNRjFBvO5NAQvGzPH6sw4q7OWw2aokfI/83T7SQxx/dYzuJVRrtYdaWJK5sCOM+5w== 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=TrXPStxZ6I79OWZ5qkgLPnAEaDwG4pQaoqTlFeMVzpA=; b=FtzSLkuohRDJc0vOrLDlAaUvUNQR9mp9ATCQoELp3/1W7JrCbpx0gCJgzuXhdS+kwoCnqlXo5wp+flCDNMavgob3YdrvQDh+i++wRLrL+xaE7r1wUkxEqVlKyZ6aIoOT7F/vvRFIjaOwyqnGcsg3R7xin3ELtCaSTgBSiFXYrAQ= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2384.namprd18.prod.outlook.com (20.179.80.150) 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 05:26:07 +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 05:26:07 +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: AQHVQf0VPcdF0o1ybE6M5aW83PjvgqbZdlWAgAE1vvCAACGiAIAAAQSg Date: Thu, 25 Jul 2019 05:26:07 +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: 868c8e56-3a61-4364-d460-08d710c098a2 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:MN2PR18MB2384; x-ms-traffictypediagnostic: MN2PR18MB2384: 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)(39860400002)(346002)(376002)(396003)(366004)(13464003)(199004)(189003)(43544003)(76116006)(486006)(66446008)(561944003)(66476007)(66556008)(66946007)(64756008)(8936002)(33656002)(14444005)(11346002)(256004)(9686003)(476003)(81156014)(8676002)(81166006)(68736007)(26005)(110136005)(7736002)(54906003)(53936002)(25786009)(6246003)(4326008)(66066001)(305945005)(478600001)(55016002)(446003)(229853002)(6436002)(102836004)(3846002)(6116002)(53546011)(6506007)(186003)(2501003)(2906002)(74316002)(52536014)(71190400001)(71200400001)(5660300002)(99286004)(86362001)(316002)(14454004)(76176011)(7696005)(55236004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2384; 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: BRs3i9KI1MKOAeIgwpk9Blh0A3yRsJDMMqHhsicAmrx3KjKpxsyCU7koWHt10Lhty6zEFKiOz0InyaIPy8NQQ4VCax50ipItzQ7vwMJ0Z88WMb9f0X5/uyH2B2u4NFaFuKx9dmP8mIYxBfp0VflRIemHdMRCP4GHmUuQ+f3q5dLMxffEn6+GYKzObW+JhrTfNelVKrBu2HXR0cZCRKbGIhX4gxSxRgKBZwHgUgq1ScNVwmWlxODqlwovw7MZ5SkMMPHDfGVD1+nl+X0ZIq5SdD+WrHBeKEkJxU+SwcA0LH7QohvMnz6YWNw5aHxTmeXlFgFzHdzdeTQXjK7LOdIrML7hqkIVhsV3NhM9L2mSXxh+/k7aDoyA04icSMVbTY3q6BaEpKloPo0y4p1CZ7WoYtJ0YIsqN/WTiLPq031Now4= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 868c8e56-3a61-4364-d460-08d710c098a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 05:26:07.5238 (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: MN2PR18MB2384 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, Oh yeah! Should've noticed. My settings is to use the incoming mail's forma= tting. Mail Ayuj created the issue. 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. >=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. >=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. >=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. 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. > 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. >=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