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 6B1D0A2EDB for ; Fri, 6 Sep 2019 08:08:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A6B51F11A; Fri, 6 Sep 2019 08:08:30 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id DA1101F119 for ; Fri, 6 Sep 2019 08:08:28 +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 x8665YST018060; Thu, 5 Sep 2019 23:08:27 -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=XFoo2b0W8SSP7knZj87x5mLKG5+k50SqClS89ye2A7A=; b=G4Rd+16CQy94bWuoT/PRXfx213sjJ96WP98XR+cpKK2zScFlE7SmAixD+DfQnOf4iElw NcoY47nqLGiBe9KnkCve8iHYdBGWmpCeuIQeCOpuldrK456WqJjTSUT2QAyE+Dv5VSyf Q9M/O+eNbEqgovS93GVDE5ZDupeb6UzeQPGlIrL1hhoXrbN0pREtEagdIJIJkvD6qghS y7VJCMe5BsQUrEJIjK29AkYtbLcAnen9JguOMydVpjQiz4bCepPYnia+Y9x4xOP9Gxck CXnFSlIPhxcKmgZkGhu6Sod4e2mVc8q5twBULYXHyuBGXJAnTG2v+8HOZGd6/6ENp+up rQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2uqp8ppybn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 23:08:27 -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, 5 Sep 2019 23:08:25 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (104.47.48.58) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 5 Sep 2019 23:08:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bkJMu3GSdViD5wcaGLiyTC+iVGW8avxsyAJxKKZ8B803ASWgCnL/KCuVccs1akoDCZxLDD2CLscUDYfBJniPTD1OVnU1e/dn9N77BKhdYFIqnGXMFITlGknK7Yh+BrUARdu5Z1Cw1UvZLJpK5+5n52EPAAxuWBhm9KUhVX1P+eqwAXKEKBTTddRhhTwuLx+F/MyMxa3i+nbVUiXaoiNL+z/CXYBFHxSE2wU/92sbl6yxmoWTiBTpaa5EKNVrvImTa7kJuxRyBvg/ydD6xdxdEYNWH+DxTIGyzJfDIQyVwY0ifvePZBQURXNTNNZ5LZ1i3HnYLVwGvo+0Nsq/ooQHRA== 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=XFoo2b0W8SSP7knZj87x5mLKG5+k50SqClS89ye2A7A=; b=Ngstz6/yBcN4hnYs0w/oDNUJdp/xk8o8RbWThaXjAOBksvIlu3BrvSrw300uaBu54MCAxn1vhbxcSt46aIwUjXUnQ8UtfkymtVIjnfoOAzFh2pjhI/DocPPi6qgs4lDFEbASUnLKg+Png76fT5GlG7nHb9ohn2syj1R2l7gzJjdiGuoxyvArWBmMD75jF6wUZYhET1RaNVkmahrX3+AwCm1d1gKXe/C7cFpJWqUVRByl8gZ5DuTSk7ImXjx34Fjbbhn/BoyPCr6q6c+vSoXaOFXTuH0DsS1IlX2cLEseh2mL3Xxd6RISNl4iXUFRSCamWXtGNxsEmH23reH8k+iASw== 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=XFoo2b0W8SSP7knZj87x5mLKG5+k50SqClS89ye2A7A=; b=wKj6Yb7KWYDrsdgxcGb9be9LBzn13wiiq+oXuFLHeSR21wlmvpTeaYMxcplkDkljKEHLbBaUA8aHJq1rTVOBpuLhqp05w1Rjx+AYxwyB7FrKuXlc8erAZZeD1ikf16ejg9y7ChyQR3oE1mGNHL4U7QM9KkLB6StO/SrU3Rk/Qlo= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3008.namprd18.prod.outlook.com (20.179.84.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Fri, 6 Sep 2019 06:08:23 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::7cdd:71d0:6771:4bed]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::7cdd:71d0:6771:4bed%6]) with mapi id 15.20.2220.021; Fri, 6 Sep 2019 06:08:23 +0000 From: Anoob Joseph To: Shally Verma , "Kusztal, ArkadiuszX" , Ayuj Verma , "akhil.goyal@nxp.com" CC: Sunila Sahu , Kanaka Durga Kotamarthy , "dev@dpdk.org" , "Trahe, Fiona" Thread-Topic: [PATCH v1 0/2] declare crypto asym xform immutable Thread-Index: AQHVQf0VPcdF0o1ybE6M5aW83PjvgqbZdlWAgAE1vvCAACGiAIAAERlQgAAanACAAGzMAIAGGgEAgDuSnoCAAFPBgIABAe0w Date: Fri, 6 Sep 2019 06:08:23 +0000 Message-ID: References: <1563958317-480-1-git-send-email-ayverma@marvell.com> , <06EE24DD0B19E248B53F6DC8657831551B282E1B@hasmsx109.ger.corp.intel.com> <06EE24DD0B19E248B53F6DC8657831551B2975BD@hasmsx109.ger.corp.intel.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: 939910f8-7051-413a-ee3f-08d732909ff0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB3008; x-ms-traffictypediagnostic: MN2PR18MB3008: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0152EBA40F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(53754006)(189003)(199004)(30864003)(99286004)(54906003)(110136005)(316002)(561944003)(5660300002)(33656002)(52536014)(86362001)(7696005)(305945005)(102836004)(55236004)(53546011)(6506007)(186003)(74316002)(26005)(11346002)(476003)(7736002)(446003)(14444005)(256004)(71200400001)(71190400001)(76176011)(2906002)(66066001)(229853002)(8676002)(3846002)(66476007)(486006)(64756008)(8936002)(6116002)(81166006)(81156014)(14454004)(9686003)(55016002)(53936002)(2501003)(66446008)(6436002)(66946007)(76116006)(25786009)(478600001)(66556008)(6246003)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3008; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: zV1h7s3qNz+3XIzNRdW5Yhg3EMg4WHGoZlSmCEUdtN3Jm8VzB2gWQ28Po1RbTE5byq0ppBvCmtenwIY9lOcC98fMa9NIM/ACLsyhmRMCea/wCfhoovbqQbIrCUJXePlmsnccNrALmXeFzl4hwEvuBFVZFvqG6R2pODcTl96VixVAAZw3jiyWfOq3yBpEWenN+oeY1FlouV+eaifjpIRr3crcF8Kn1UK2HnYSs+Ws7a31ZnjbAUokX6yhYJudoKusjSweKyPdv897j3yV83yk6gQhwLNBtIVL22DcfY8ART+dPC+A/FKpS5vjhL+aam5vIs5WJDX9HlCqE5Fz+AlZRvs0J03LQtxFOiuR271sfuISIxA3LhdoKSKXSPmlBiwLt1uVqMS8Qz/f3nc6XzLSLJmQ5fhDWo1mQ+0/nIf4A/4= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 939910f8-7051-413a-ee3f-08d732909ff0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 06:08:23.4741 (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: 9QxfLDqkjRjrn+S7LYKN3aRscIrHOM4ZGLxXnuPkqMdTaLfe8noV4XUmRl+CiiukPX6VG8Zlgg6OBGENtUrEOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3008 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-06_03:2019-09-04,2019-09-06 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, Arek, I still think it's a bit too early to take a decision on this. 'xform' is b= eing used for symmetric operations as well. Everywhere, 'xform' is treated = as an input argument to PMD ops. Making this change will define 'xform' in = a different way, and that will be applicable only for asymmetric. I believe= we can wait till we have a PMD which will be able to fully leverage this. = Moreover, the same behavior could be achieved with session-less, if we decl= are that the number of operations done is "few". So my opinion is to push f= or session-less now and if it comes that the session based operation with i= mmutable fields is superior to session-less model, we can purse this change= then. Also, the main concern here is that the library will become more prone to e= rrors. Issues arising out of this would be hard to debug. So if we make thi= s change, we should make sure there are no better alternatives. Following is something, that we often do, xform.abc =3D 123 sess1 =3D create_session(xform); xform.abc =3D 456; sess2 =3D create_session(xform); do_operation(sess1, op1); do_operation(sess2, op2); With the said change, the above could give bogus results and the code would= n't look buggy until you read the documentation (and understand the usage). Thanks, Anoob From: Shally Verma =20 Sent: Thursday, September 5, 2019 7:52 PM To: Kusztal, ArkadiuszX ; Ayuj Verma ; Anoob Joseph ; akhil.goyal@nxp.com Cc: Sunila Sahu ; Kanaka Durga Kotamarthy ; dev@dpdk.org; Trahe, Fiona Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable Hi Arek Anoob has to have go, no-go on this further. Regarding your question on ses= sionless, have you submitted POC for same? Thanks Shally From: Kusztal, ArkadiuszX =20 Sent: Thursday, September 5, 2019 2:52 PM To: Ayuj Verma ; Shally Verma ; Anoob Joseph ; mailto:akhil.goyal@n= xp.com Cc: Sunila Sahu ; Kanaka Durga Kotamarthy ; mailto:dev@dpdk.org; Trahe, Fiona Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable Hi all, What is the state of this patch, is it intended for 19.11 release? I would also propose to extend .rst comments to session-less case too like = in this thread below (with [AK]). Regards, Arek ________________________________________ From: Kusztal, ArkadiuszX Sent: 25 July 2019 19:57 To: Shally Verma ; Anoob Joseph ; Ayuj Verma ; mailto:akhil.goyal@n= xp.com Cc: Sunila Sahu ; Kanaka Durga Kotamarthy ; mailto:dev@dpdk.org ; Trahe= , Fiona Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable=20 =A0 Hi All, > > > 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. > > > > [Anoob] In the patch, the edited APIs doesn't have experimental tag. I > > leave it to Akhil's judgement on this. > > > > > > > > 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 time by > > avoiding unnecessary memcpy of keys buffers. > > > > [Anoob] Contradiction is in the sense of what is a session. Here we > > are saying one session can have SIGN & VERIFY, but the lifetime=A0 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, > session data should not be manipulated. [AK] - we need to keep in mind that if we will copy user private key inside= our internal structs, It will be stored in two places in the same time, making it more vulnerable= , that's why I have asked about session lifetime. At least we could inform user of this when PMD copy data internally. Of course usually this data need to be copied anyway for op lifetime (becau= se of some padding/alignement requirements hw may have). >=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. > > > > [Anoob] The current change could break existing applications. And the > > compiler will not be able to detect it. > > > [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 > change. >=20 > > > > > > 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]=A0 Compiler may or may not warn on typecast error here. > > > > [Anoob] May or may not be? > > > [Shally] Yes. Depending on compiler version type or optimization level. > Havent given try to all. [AK] Integers conversions are not good example as integers in C are governe= d by different rules than pointers. In terms of this -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 struct = rte_crypto_asym_xform *xforms, +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 const s= truct rte_crypto_asym_xform *xforms, No compiler should complain about that as per spec: for any qualifier q, a = pointer to a non-q-qualified type may be converted to a pointer to the q-qualified version of the type. We of course expect user will not change this data when there are still ops= to be enqueued with this xform. [AK] - This note could be added to the session-less case. [Ayuj] Yes, also can't do below : =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= const=A0struct rte_crypto_asym_xform *xform; =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= struct rte_crypto_modex_xform *xfrm =3D &(xform->modex); =A0=A0=A0=A0=A0=A0=A0=A0=A0 it should needs to be const for both which will= ensure its sanity :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= const struct rte_crypto_asym_xform *xform; =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= const=A0struct rte_crypto_modex_xform *xfrm =3D &(xform->modex); >=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 > > session. > > > 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? > > > [Shally] We don't know how every PMD might use them. So, it is safe to ma= rk > xform and buffers immutable there too. > So this is my thought but I have asked from POC for sessionless, as it is > proposal by Arek, am yet to get more feedback on that. >=20 > > > 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.=A0 If we > > > don't change spec to enable optimization, then we're making > > > 1-approach slower than other.=A0 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 > > 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 > > 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 m= ore > cleanly. > > > [Shally] There's no rush. It is up and open for feedback. > This change has an intent to optimize session setup time and since xform > data is not supposed to change once it is set on session. Only change > proposed is, why not just use app buffers instead of redundant copy of sa= me > into PMD buffer. > if you see better suggestions , please provide. >=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 > > > 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