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 BEE05A046B for ; Thu, 25 Jul 2019 07:21:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 848C31C272; Thu, 25 Jul 2019 07:21:54 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 00F8B1BE2B for ; Thu, 25 Jul 2019 07:21:51 +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 x6P5L3xN029823; Wed, 24 Jul 2019 22:21:51 -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=N/Ww+HDWEKZ5xuVSTCYbgZSPaV9N5AupevL4R9P+/Ss=; b=THCV3nWYmNRtvacHtUlwX1oWzib/8KrvUbiAvxmJnl/bPiqdzFqSJLw++aRjZf6lRSb4 egeQxgBYrPN9QlCOjpphJ5RNJPa80l/SBG10B7dlKKat141x2AZZZU8RfHUrwJrBqYAe jQ1uBhMDpUZMzQQAB+fzsojl8zK4oHdSykkb+fEUW/75gtIyuzMyCKhxxEhty2aN30mD P87yGNbcbzD6xSMlD4EmfcRTAJtXvKUQwq164N5ijc/v4QwGH81yN6LnXaQhM9Gil09A XBjGO0PKIuPC4G0HgthdvTs1M+5FjoUzIBNK74BGi5r8z3DAjtI2rnac7Suqe14FXVot Pw== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2tx61rfykq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jul 2019 22:21:50 -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:21:49 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.59) 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:21:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BZ03iyJMfpOmT7Hu9/ZIO1l88y7L1BTpWB93swfqmxTOLSYrmtk9/vilAWheTk8ArXmc48jItZ94/Fm/KF5sM766FtXkPQOo2Sizll5IFLmbdkS6wXiSw6FTpQgnQHrX5vRQzxfh55lATi5r4dXgLOfc/U7aEee0pxpdcMHPQkeSy5/zIPy7ic2CWjnDCwaH1fQSRfgobeQDvjziG4hLqyGzAfFDOHLi3VD8Qr7ffQDs4OEhy8DXuk/pkgZnMHdLOesMY5iEv7wbfW3L9d6qP7eolPjhHSjPfyT7mt6VKyXDhaVflXruyGel1kWCkPmb4oLU68T2k3yQ+FY9v2/qWA== 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=N/Ww+HDWEKZ5xuVSTCYbgZSPaV9N5AupevL4R9P+/Ss=; b=bCKXD3xmpAMNOJYRPhBNyz0l54ydqdAkhHOX2VM+YJgwMUbY6GRdgGAVyHfzJ0KIahhyib3HStOwzg1FPE80L1I5SmChKmadNnTxn3vRhLHorj2SMVZFB3C1pZbJ3AAjJDk+wg62YegYj7HGvC7KwpFylWHp9ZVT/8COVe+3IGLnwpDP+EXu/2gCRx+8wrT1RweSReIzvt0TA/hRp+6e6xy3NDvL/QqLie44aszLRDTpEcw+ITgMbEc3US3vDiOZoILchiwVXFyV2adFreTV8DMULNM3U46yToAQ+jK3F495VESwCKNcEwWf854BKzdppjG4/bs15d4a1AcpoVGO4Q== 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=N/Ww+HDWEKZ5xuVSTCYbgZSPaV9N5AupevL4R9P+/Ss=; b=wFV453YA09ov2ifn62Vfv3iOV2JnSnXO54+GdoOY49FuheT3OCYIVp3MyJfD+N0R3TFU8aVsQFHcyijyBNMi02uaAwuzzyNzr5h3O5lTnh/mm16DDZGOsgr9F5UokH3gUn3LAArSBjmO6mTteg8QUYBsaOyEHwoK0B8rvDVQIyc= Received: from BN6PR1801MB2052.namprd18.prod.outlook.com (10.161.157.11) by BN6PR1801MB2035.namprd18.prod.outlook.com (10.161.157.28) 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 05:21:44 +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 05:21:43 +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: AQHVQf0VE8fh0pVNEkyFNFVWwsyWkqbZdlWAgAFE6YCAAAg8YA== Date: Thu, 25 Jul 2019 05:21:42 +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: 4381f769-7553-4dc7-3aef-08d710bffaec 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:BN6PR1801MB2035; x-ms-traffictypediagnostic: BN6PR1801MB2035: 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)(366004)(396003)(376002)(39860400002)(136003)(43544003)(199004)(189003)(64756008)(25786009)(76176011)(6246003)(66476007)(229853002)(66946007)(81166006)(186003)(52536014)(53546011)(561944003)(66556008)(102836004)(5660300002)(76116006)(486006)(6436002)(26005)(66446008)(55016002)(86362001)(55236004)(8936002)(14444005)(256004)(478600001)(9686003)(81156014)(53936002)(71200400001)(3846002)(316002)(8676002)(110136005)(71190400001)(68736007)(54906003)(74316002)(4326008)(2501003)(33656002)(2906002)(6506007)(99286004)(476003)(6116002)(11346002)(446003)(66066001)(7696005)(305945005)(7736002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1801MB2035; 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: PG84q6+0ma93ORL/3SjZeHLwGnjtS7embrpdEgMgY7a+gfc22lypNcNosflPxzHkeZkyGRYQMYtvMgTJxeaD75/eEQqqlg86Cc6kqyM0bGpodzTpgCi8R6/M6E/pbiZ7d7kFD6IHHnfrKbOgwcu0CaQ72B1oJnCXBL/PyUGxhsH5xwiwoJ8YMY1B27xAleGaxmhT22zTd+MNn9OoLEkDo6eBUCDoynBa5xhqEIIeLXDrQo0S4egH4sugAQt78ai1NUcvdQD/49wa3f3vIoDfa8ty84/htRjtdaJpNqzdyEAo/MQZwugoaUeU97BUTnxykipGpQuPKCyRQa5wEXUMqDPAV140sN0vvPOJj3Ms+dLNizp/1/Z49s2mJMHCcYIYY1h8py6llyElkSR/g2SiMyog+OgPkfz/KCSncPNc1Hs= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4381f769-7553-4dc7-3aef-08d710bffaec X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 05:21:42.9049 (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: BN6PR1801MB2035 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 Anoob Seems your reply is not in plaintext which will make it difficult for inlin= e response. So, please take care of that when you reply. Rest, please see my response inline. From: Anoob Joseph=20 Sent: Thursday, July 25, 2019 9:46 AM To: Ayuj Verma ; akhil.goyal@nxp.com Cc: arkadiuszx.kusztal@intel.com; Shally Verma ; Sunil= a 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 a= nd I'm not sure if it is a right practice to edit an API without deprecatio= n 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 chec= ked about it with Fiona, Akhil before. I think, the approach here is wrong. If the lifetime of the session is expe= cted to be only few packets, then session-less (which I believe is in the p= ipeline) would make more sense.=20 [Shally] See my response further below on this. If the lifetime of the session is expected to be more than that, then havin= g this feature/limitation would make application more complicated. Also, si= nce one asymmetric session can hold both public & private keys, the implici= t assumption would be, the session can be used for multiple kinds of operat= ions. This change is in contradiction with that.=20 [Shally] Why the contradiction here? There's no change in session usage fro= m 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 changin= g is, PMD which does not need to store keys in specific format (like openss= l PMD), can just hold app buffer pointer till session-lifetime (eventually = giving same effect as sessionless). It will help such PMDs to optimize thei= r session setup time by avoiding unnecessary memcpy of keys buffers. 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 i= s 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.=20 [Shally] This spec says " xform and its buffers remain constant" . So, inte= ntion is to state to apps that buffer passed to xform should be const in na= ture and that they should not modify 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 abl= e 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-les= s, this seems redundant. [Shally] Compiler may or may not warn on typecast error here. That's why s= pec and documentation are put in place to ensure that application don't reu= se them or destroy them once "xform and its buffers" are set on session. An= d, same will need to be documented about xform for session-less usage as we= ll. 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 wo= uld 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 implem= entations ( like ours) , believe it completely make sense to enable session= s to have sessionless effect. If we don't change spec to enable optimizati= on, then we're making 1-approach slower than other. PMDs can adopt any app= roach more suitable to them. But spec could be made flexible to allow them = to experiment with both approaches for performance. Else , PMDs will be for= ced to experiment around sessionless which may be eventually be an unnecess= ary overhead for them.=20 Thanks Shally So this change is NACK from my side. Thanks, Anoob From: Ayuj Verma=20 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 ; m= ailto: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=20 =A0 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(-) --=20 1.8.3.1