From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 11DA2A04A3; Fri, 17 Dec 2021 16:58:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4C164013F; Fri, 17 Dec 2021 16:58:52 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 4C98740040 for ; Fri, 17 Dec 2021 16:58:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1639756731; x=1671292731; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u9GRADCndj0saLWqUTgJE0E8A8Cj8PssalBFZFnB+5U=; b=RBYEAGeCK0WFiSQ8Ab5vSvYBSW33enzNoWLNAlZ3Ogt8ecjVqMH/49xd rxvPJUGy9+NgzpTfZFr+bM/thpk4rT485Jzf4CM6hB3C9bvelUkt1Ywqd RIVkrhhO6/gqdcVIa8B8iOkdFyx6X/QOkJMBfbJ1ItB6HACt58Au22nhS vObxuVAIe63dTi2wfjso1WM/YIB0romoCxGnjCHSGTpaqdVnyRZzUwoY6 NMQScA9jLaoHCtnkHEAYXynh53s0RtmKv3N48SmOTYeGdFbC7GDZDh0sX pftBvxApJvJ9YlvZ9gTyDfO6nvDgQ06zcuVC9vZEdfZjs/rdiGinYSQ0D w==; X-IronPort-AV: E=McAfee;i="6200,9189,10201"; a="226634150" X-IronPort-AV: E=Sophos;i="5.88,213,1635231600"; d="scan'208,217";a="226634150" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Dec 2021 07:58:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,213,1635231600"; d="scan'208,217";a="465158245" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga003.jf.intel.com with ESMTP; 17 Dec 2021 07:58:49 -0800 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 17 Dec 2021 07:58:49 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 17 Dec 2021 07:58:48 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Fri, 17 Dec 2021 07:58:48 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.100) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Fri, 17 Dec 2021 07:58:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gIdoNQC2r4MmdnFDVQJCOjTXrfzzqYbaj30lFk9vwF3XfduMYLn1Ld1O0biQ7WcsYVY9a6K4bouqxfJTGnmeLl/d9fzgKqkUt3ryiseun7dYSuv3h+AA0Iu7RhpTLAZlR84j4l1t77QY/+9+invrJOYayb+eoBcrJqenk+f02DlqD6lpSOGnDSprB8VQ5ujiwoYzYNZ3TC1xfTm6s0RKOoL3WRlqVbQ1CHMm7X8eNvwhLCDzdzE1UVeWr51oOiNVU9XIt3Qg4nDBYfDmUFG+ezjlpnIynJOUV5ZkWhxRGGINljLUVoTQlXHGGMQeFJj93SZuEeaEzSOr6b0ucAkvKw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hCBgihEGVnpb0WV1QYxKyaBV2wsx+2CMBJqSItQI3EE=; b=lOasTw4qSr4024MYAlFI8aCSUzx7zz0CscyL2SpaNQjzH/6iK6iIu7OvBzQS0Y2tTcFSyPkbIfpRp1Vgk6hIsxlc1z0xJjF/rZVgLroyCVmdiUcd86uapzq13OUUxBYp6gEVBfwbAQ+sdRXW1hfTvxUJgarff63JUGSVXpzLF+KGJbDVhJLAT0Kn0wjY9NazaNOFOxhutjlgIKpj3YjiMJ/c4VI1cMYdlt6YeU9gk4HowN3II3dteWGjUuIVbHb2o2/QMUFB8GCOmbeNEChLLzfc4C2NSyoNuvHxgFVWAPZVCV6gast3v/h3ClIQ3XywFwD8+lr/xxRLr9XTWx1Qiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH0PR11MB5013.namprd11.prod.outlook.com (2603:10b6:510:30::21) by PH7PR11MB5915.namprd11.prod.outlook.com (2603:10b6:510:13c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Fri, 17 Dec 2021 15:58:46 +0000 Received: from PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::119f:7b25:561b:1c72]) by PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::119f:7b25:561b:1c72%6]) with mapi id 15.20.4778.019; Fri, 17 Dec 2021 15:58:46 +0000 From: "Kusztal, ArkadiuszX" To: "Zhang, Roy Fan" , Akhil Goyal , Anoob Joseph CC: "dev@dpdk.org" , Ramkumar Balu Subject: RE: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constraints Thread-Topic: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constraints Thread-Index: AdfoK7ceQgkAkP41RgO3JecgFn5yogH0pOlAAKP2+FAANBTMEA== Date: Fri, 17 Dec 2021 15:58:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.200.16 dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbb49893-c102-4b38-87ae-08d9c1761b8b x-ms-traffictypediagnostic: PH7PR11MB5915:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Hyh9p3h9oejCG/63InDSum9rgnBjpjAVqwQV3gUGithK8/efIcsz5e6NOpo7dNYh+l9Xfh+bYhjFUI73Jp2EdouounMlo8d3bIOuQ4teGTb7avbGYs4XlbCMtFm3+6SC0A/ObkQTqL52E54b6oRnz/uFjp4CRrLL+OLryDgdmnCRbIdbzrktGfsarjqX9OoFNYib2yUmNpDP82Xp+J5OeErxQOgG9fzqJRCROUxntvyNaOwbXFFPT5LqmQOoe6jy3Wv7D+FuHYSNxHMz9JSrWzYJao3X7mLyUCevypHaxjRNoSHL80M8W/XXT1ZcfNdZZ7Yd8dj6mfqQdId85OYo3NOypro3t/sUvhaT+fmpf4NWfbp149WiV6AVTzj+lEc9sBCGYxkXBfOdlqjNORe1mAym2kI1lBarlyxySAwvXYkeBJ6woEpxyqSJGzwo52jrT0a17zfJlfCrRuf5zQZU7oKJu2o8EtddvOlY7S9SthzGR65QBUPTTeyObd7f9UnilfNgRaZixRKQZV0JX1Up/OyxTtd//Q3anU8tN4WjLjploHxHVeQDdaDCRGCBiNHYtSn1EdgecqXPGbGsvfzYXocW+Hdn/5LJUauc34DSBabTP8ndrij/OI4G8T8HxHudkm0cD/wljdHf1pdNm8P7Zh6zNVBnQgyEIDMhDwCMXDnTq08q58AKIs2fTnMFq2aTxUKLhQH0IKcT4lusMWgBdA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5013.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(5660300002)(122000001)(9686003)(26005)(6506007)(71200400001)(508600001)(55016003)(83380400001)(4326008)(82960400001)(54906003)(86362001)(110136005)(52536014)(316002)(33656002)(53546011)(7696005)(8676002)(38100700002)(186003)(8936002)(2906002)(66476007)(66946007)(64756008)(38070700005)(66446008)(66556008)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qM237ZddcBhZQQUUnFlqtVGC3WOnfxKa8+wnSr24PLUvjfseN7SpT9xURG8S?= =?us-ascii?Q?Lblu9xuVqLrDYYlOA6g5Ir0nn2CtoS1qIEc9wCPaIbCedIsFPY4/7IXe1oWE?= =?us-ascii?Q?UG8T/f7dqglshMFfvMQJqYUhy4kw4seUxGjLaKdjELVp6flsrcofi/9E8y51?= =?us-ascii?Q?VR3zrDrO9gQ5SThPBZx9WzbPYFuwc4BR8uikT6haHIl26CMsDyU3VlhvodI3?= =?us-ascii?Q?mcNV6f7ThitwEUh8335Ycjz8ZFvIWKJ9GIbhvzRYhWG4Z10P6kKq+/YEjmCM?= =?us-ascii?Q?3Jg8iFUQwnI+GrrERrVOyvTZlAX+0C7aB3ksWga4c1Qqj26Nxk+e4GD0GaJN?= =?us-ascii?Q?7SzCZhSjCuLrEgjaMCZNxbRIv7wH6AWeW0jjzrsmaDVwX2w6JmfcNamchkLf?= =?us-ascii?Q?CLCnsqVGaMAqSjgpLCxULcOgdvqXlTtvA3I8uS7KaEtQrRsoZYSajO95MEOX?= =?us-ascii?Q?LGHemPsY8mEEmE8xDryZdfKM1B0oj9ULpoobckTxVim86n6FgfDEyMtKYujM?= =?us-ascii?Q?NqzenOLiTKW6IOAWVHwrCrxAK2x/0vb3opvKSWP9GRHFuhmcbbwkFX0uX7LC?= =?us-ascii?Q?cD7/a9bPMHTcWiHTA44oBvpinHN1VAEvoKiarTYWveiF2wGR8IE/ybM0lT2Y?= =?us-ascii?Q?eBZnAQn5FlhxPecZ+9R3rTjLnjP+tqH49X/Fcc9AmOQqXSlpwh17/XBhNU2R?= =?us-ascii?Q?9MSLFVLUBc3CW87f/YcbXMgMCRoqGs5YzQEWUMLm9gV+3HeSPIiqRgbeJijZ?= =?us-ascii?Q?gImL0kHzWCoS5cudTx3jQoGcHXM601vxGjL70OOqjny9GqKiC2D0hl7CxDqR?= =?us-ascii?Q?/rTYlpyas7tcbyM4Y/mgLiEMtsmzgTmGyFL8c6LJK2pPnM63adsUNQ7ZrWru?= =?us-ascii?Q?hMwrHBmqc7jkyLa6w4jAhe5VVyZGMThITi4zGTtSgFBfUI93VgMDtYoyj4rC?= =?us-ascii?Q?n8xcPZCejjvjZ2Sazmkr6gmJYBzdfJR21jWeLL/QaP3PZqIgMLIEsUFvDHmJ?= =?us-ascii?Q?0OWf8uCeEUXwdx2i9frtpaKkH2dAsfcKuczAvRHsOSD+2tZis6DWNekV39hl?= =?us-ascii?Q?KGNg8LbdR2IDfmYYydFCzN8a/s7BK122U1Nq0XQ7D+ojR6eQ9HgQYJAFqVlQ?= =?us-ascii?Q?1UR1zogR1TXM4agG8uosqcAMlUI/BsCfaMxFsqgE0IvItJ3hmIAdMyZy9j0B?= =?us-ascii?Q?KOVStVaARJ1PInxxF7E0fevpkOz+BdgFfy5bjaWVHPKgO6GciTJN04KLYeLa?= =?us-ascii?Q?IuFUSZhqSmeHzfl2pZcAAfUpUqXnaxApBhT2lYlGoQEoD29P19FAPXBk49nr?= =?us-ascii?Q?ZINyM2s1uoM3olJFitVvsm7ApgWj/9lCQwJFjC1QNIWHg2+SOd6rhubuEMiB?= =?us-ascii?Q?7Vz5+mJ+BdNH3NV36ky6qtZYtOB0t+YAtTCa+JB0IgR8qczLtJs685cfJf/+?= =?us-ascii?Q?IDimtcUUP81KPqhJRBdRiwyGF7Ee7Il/k/JEV3H90RzMeVQL5fkzXgVN2Q1o?= =?us-ascii?Q?xFQQNQ+YWAlGnn87L9cOgGwtrN+FJh2P4V+1tkjoeSbjBoHGTnuBpQpkEYMB?= =?us-ascii?Q?iFuhWOHAXsDY74mIya1XIloy4jnSUBMVuKlzOzR827CTIxyV6tAJCDFxWSrx?= =?us-ascii?Q?inUQEI/seiCc0nmMOZn42vcRap+LRCYgPOFuyUjZfWTS9gGonGVhmaOeGzKu?= =?us-ascii?Q?7TF+zw=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB5013EBC006D908D50864441B9F789PH0PR11MB5013namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5013.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbb49893-c102-4b38-87ae-08d9c1761b8b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2021 15:58:46.0324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qfS6YdlxK6QbcZLEqYBXGcTA+zuMwzX1Ym9reKFcopmIoBdIa5GLXPgiKJDvGI7iakeFYD2IKtnTmysdJxTu36skJJ6+yh0dWDYBH7VPmuM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5915 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --_000_PH0PR11MB5013EBC006D908D50864441B9F789PH0PR11MB5013namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Zhang, Roy Fan Sent: Thursday, December 16, 2021 4:05 PM To: Akhil Goyal ; Kusztal, ArkadiuszX ; Anoob Joseph Cc: dev@dpdk.org; Ramkumar Balu Subject: RE: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constrai= nts Hi, From: Akhil Goyal > Sent: Monday, December 13, 2021 9:36 AM To: Kusztal, ArkadiuszX >; Anoob Joseph >; Zhang, Roy Fan > Cc: dev@dpdk.org; Ramkumar Balu > Subject: RE: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constrai= nts Hi, since DPDK 21.11 is out, we should start discussion to make asymmetric API = stable. - Struct rte_crypto_vec vs struct rte_crypto_param_t We have two almost identical functionally structs, one in _sym.h another in= asym.h so we probably should pick one of them. "rte_crypto_vec" additionally contains total length which will be useful in= formation as PMD will overwrite "len" in many cases. Unfortunately as "rte_crypto.h" includes "_sym.h" and "_asym.h" not other w= ay around we cannot move it to "rte_crypto.h" but asymmetric will include s= ymmetric anyway so it probably will not be that big of an issue. [Akhil ] +1 [Fan] +1 - Network byte order rte_crypto_param dP; /**< /**< dP - Private CRT component * Private CRT component of RSA parameter required for CRT m= ethod * RSA private key operations in Octet-string network byte or= der * format. * dP =3D d mod ( p - 1 ) */ We have plenty of these (sometimes in places where should not be, and not i= n places where should). Every member that contains this comment here is a b= ig integer in big-endian format. We could simplify it to: /** Big integer in big-endian format */ typedef struct rte_crypto_vec rte_crypto_bigint; rte_crypto_bigint dP; /**< d mod ( p - 1 ) */ ED related algorithms like (EDDSA) will use little-endian bit integers so i= t will have to use different approach. [Akhil] Using different approaches for endianness may not be a good idea. W= hy can't we use rte_crypto_vec for LE? It has a void * data. Right? [Fan] Akhil, do you believe a comment before the param is enough? [Arek] - Yes, for me it would be rte_crypto_vec for LE and rte_crypto_bigin= t for BE, which would correspond to what other crypto libraries propose. --_000_PH0PR11MB5013EBC006D908D50864441B9F789PH0PR11MB5013namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Zhang, Roy Fan <roy.fan.zhang@intel.= com>
Sent: Thursday, December 16, 2021 4:05 PM
To: Akhil Goyal <gakhil@marvell.com>; Kusztal, ArkadiuszX <= arkadiuszx.kusztal@intel.com>; Anoob Joseph <anoobj@marvell.com> Cc: dev@dpdk.org; Ramkumar Balu <rbalu@marvell.com>
Subject: RE: [RFC] Cryptodev: use rte_crypto_vec, group big-endian c= onstraints

 

Hi,

 

From: Akhil Goyal <gakhil@marvell.com>
Sent: Monday, December 13, 2021 9:36 AM
To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Anoob Joseph <anoobj@marvell.com>; Zhang, Roy Fan <roy.fan.zhang@intel.com> Cc: dev@dpdk.org; Ramkumar Balu = <rbalu@marvell.com>
Subject: RE: [RFC] Cryptodev: use rte_crypto_vec, group big-endian c= onstraints

 

 

Hi,

since DPDK 21.11 is out, we should start discussion = to make asymmetric API stable.

 

-        &nb= sp;     Struct rte_crypto_vec vs struct rte_crypto_para= m_t

 

We have two almost identical functionally structs, o= ne in _sym.h another in asym.h so we probably should pick one of them.=

“rte_crypto_vec” additionally contains t= otal length which will be useful information as PMD will overwrite “l= en” in many cases.

Unfortunately as “rte_crypto.h” includes= “_sym.h” and “_asym.h” not other way around we can= not move it to “rte_crypto.h” but asymmetric will include symme= tric anyway so it probably will not be that big of an issue.

[Akhil ] +1

[Fan] +1

 

-        &nb= sp;     Network byte order

 

        &nbs= p;      rte_crypto_param dP; /**<

        &nbs= p;      /**< dP - Private CRT component

        &nbs= p;      * Private CRT component of RSA parameter&n= bsp; required for CRT method

        &nbs= p;      * RSA private key operations in Octet-stri= ng network byte order

        &nbs= p;      * format.

        &nbs= p;      * dP =3D d mod ( p - 1 )

        &nbs= p;      */

We have plenty of these (sometimes in places where s= hould not be, and not in places where should). Every member that contains t= his comment here is a big integer in big-endian format.

We could simplify it to:

 

/** Big integer in big-endian format */

typedef struct rte_crypto_vec rte_crypto_bigint;

 

        &nbs= p;      rte_crypto_bigint dP; /**< d mod ( p - = 1 ) */

 

ED related algorithms like (EDDSA) will use little-e= ndian bit integers so it will have to use different approach.

 

[Akhil] Using different approaches for endianness= may not be a good idea. Why can’t we use rte_crypto_vec for LE? It h= as a void * data. Right?

[Fan] Akhil, do you believe a comment before the = param is enough?

[Arek] – Yes, for me it would be rte_crypto_ve= c for LE and rte_crypto_bigint for BE, which would correspond to what other= crypto libraries propose.

--_000_PH0PR11MB5013EBC006D908D50864441B9F789PH0PR11MB5013namp_--