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 6A9BAA0548; Fri, 3 Dec 2021 11:01:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 28E7C4014F; Fri, 3 Dec 2021 11:01:43 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id C323340041 for ; Fri, 3 Dec 2021 11:01:40 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10186"; a="260957268" X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208,217";a="260957268" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Dec 2021 02:01:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,284,1631602800"; d="scan'208,217";a="541578867" Received: from orsmsx606.amr.corp.intel.com ([10.22.229.19]) by orsmga001.jf.intel.com with ESMTP; 03 Dec 2021 02:01:39 -0800 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 3 Dec 2021 02:01:39 -0800 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 3 Dec 2021 02:01:38 -0800 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx608.amr.corp.intel.com (10.22.229.21) 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, 3 Dec 2021 02:01:38 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Fri, 3 Dec 2021 02:01:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/q0SPzhMxKUyP5KUCKWqvhy57uceLBT+kaxsE+kUCDmoCIMP2iwrvg7aIaxIcwz6bVHwNN9nY9dZbiOa2nH56P0PmQe5h31BgGKfKB9uSsTUOiYnMO88eIxUK+0fW6njYL5SZCp0+4freiPetwfceYqMEy9h4cN6GG1n1mXtcJTFEQIlNOIOOeEcxWGwdMvC7BZMXfvxUKdoVetodwBK8J87O5Bj0KaiYSlACGBeDVuPUqLxZso2+q1zHogQLrhg69P98pFU/4xgjZYFOAOP7DqMlPR21aYM8XWm+jRWIPC1Jf4XW52+1L4st7kdSOrA+oH6/kp8Yjaa9AXb1XhMg== 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=pAmnw0chcBe7bZVJUv9yrVKgNUElvDEnwC4YVm+dZ98=; b=W298LG8nsLpOyUW+Q8RzOqwxrPeudWQAkbncWVTyb1lORLfkJe2WluHrLMlc2vXYDDWXaykyz/GZIhhdcEBxCDVxbDAQ52Bz15XmU9RSnsYiilqYlQlapva+xbP85KXVCxVEk+pQdXWtGkzuuaL9PpUC2Vhe4/IkV34Eumm4q61YE/0fqOyS7hH8kglbq4L5G93+pvrgVifh4VmKw+vjgYk9ufLNBSQBs5d+BbTPZrx96zBFmUVS3ZLcKs81TeenAlooyyakmfG2WIMWJkjyHOajYg0+NgTb5WI6WpHyfelkGRwMub10jI/Uwrveulp7rl98dAyWnxKDdOV1SBpKtw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pAmnw0chcBe7bZVJUv9yrVKgNUElvDEnwC4YVm+dZ98=; b=sWTGw08ZO2cWSqpAJNBmaZbZQVkSaSkRoYkQYaUa5F34KADTniWntZr7rs7cojcKRs2KVP3OjfiaCtOislpwN4GJXonVniIw80bm2ySOpCCSGiPZIlP3GW92XcAiwgzszYla+HAJjloJnwj6v8JuhhmodHGcfwmKLZkgpQ1I4v4= Received: from PH0PR11MB5013.namprd11.prod.outlook.com (2603:10b6:510:30::21) by PH7PR11MB5817.namprd11.prod.outlook.com (2603:10b6:510:13a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.15; Fri, 3 Dec 2021 10:01:37 +0000 Received: from PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::119f:7b25:561b:1c72]) by PH0PR11MB5013.namprd11.prod.outlook.com ([fe80::119f:7b25:561b:1c72%5]) with mapi id 15.20.4734.028; Fri, 3 Dec 2021 10:01:37 +0000 From: "Kusztal, ArkadiuszX" To: "gakhil@marvell.com" , Anoob Joseph , "Zhang, Roy Fan" CC: "dev@dpdk.org" Subject: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constraints Thread-Topic: [RFC] Cryptodev: use rte_crypto_vec, group big-endian constraints Thread-Index: AdfoK7ceQgkAkP41RgO3JecgFn5yog== Date: Fri, 3 Dec 2021 10:01:37 +0000 Message-ID: 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: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6dfe46a4-a242-43d7-cede-08d9b643e54e x-ms-traffictypediagnostic: PH7PR11MB5817: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Naif0PhtlcRpzFT9XPnzG2on5C8eCErn0GQH2dJY0H+M2iskqhZH7hCHaeaEClYE76byTgSCSrSBlqqfAHyTHYTMXPcQd5pdcxP9HhNj7zVOau5hFtw85ZSYWT125TG9SthmVHkd7jkIANc06MLiFqe2sdBA555q1ncBM8njE7nrXb221lSBnMnroabOZ+pmtMTq/Me4HinhUjRj7RdLZDaEVBe1UqbCsITsJUkspRT1Zdp/ilRjANPCeOrsO7asUwq0o1pZvBRF5Qc8v1bx9j8hqUkPtrXTtJskvXmjQqhIDaG19WkINWs+zvu9PSUaHI1ayyzemPKaS5WQ8w8UcbGerFAf53IMFcvV3lGUIUzgCakz+Az+/vpxiU8ihO3MKH97YSagCRqXG9Z9337t6xnPf+ZiczpHOhJxmjgcUjkL/7+rFY83sx/+Q/Oiol2OfWw9EUdEYiPYXUJIBLHkuxrkyH5V4BDsYOcD+IYjUE8+9dE/EeqpuXWdut3q9JCrjOYN7lhh+m4OcJajxEGwe683DQOT+aisLLbB/9wOz9rFKjBN1u3kg/v4XRjBx4MBTM2pECk8XND3S7i4qBeJ9wiBkYgk94f6NYs1frgQmvehS77Ud4jX1FqVf0JPb2xCoPltUxPB0DF7g0upn4dvvrOIoHXgXcGhrQbS5WYaq4Y3FjEeoASxC4Rj39iE3A6lIpV3DU++6vh0VpzgOhdA7Q== 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)(4326008)(7696005)(6636002)(55016003)(122000001)(76116006)(9326002)(38070700005)(5660300002)(71200400001)(66946007)(38100700002)(52536014)(33656002)(86362001)(6506007)(316002)(64756008)(508600001)(66476007)(9686003)(66446008)(26005)(66556008)(8936002)(186003)(110136005)(82960400001)(8676002)(83380400001)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Gm/JLtG7y211ROjRtVkLqRLnF1WOrCNHlQfISI3e2hZSQ9rPte8iVcSZIwRi?= =?us-ascii?Q?1Xr4TlPZRluPqizS5HKgVzMG8UjgvQf2NJtJD+rVTEawgf1KGU/+u6gsrlo6?= =?us-ascii?Q?xC+FwYLW3W4MQT23VUkB7Fo4s0wxasqw6B9NkFmD9BH9v43cwW8dK8J57gLA?= =?us-ascii?Q?6Xfg8oPZm3jcLzpX7jbAnGfEoAvsMri5fC9jVNht2VHjWLdchyXIRMuBFX71?= =?us-ascii?Q?5Vlf3/USP01XBxIGAmU5t1NmLXn6JkHWgTAqx4nenNnHnswwKbHTt08nXGk5?= =?us-ascii?Q?3IJrvvzypPFy9VEPAoRTYESm6toZ9JxZvXylfuH3Z8Ol/kdf6EPkrVxzpPwY?= =?us-ascii?Q?oSQhyxSAESsdxrY3LK6M/1Ps4NTJd5039wv+YIxcY0FOcl98rB2Ki1mxvgUy?= =?us-ascii?Q?V28E/8AnNl6cn4KoOsvXOfK2Hp/A8ru/txyNnjSQJs34e/iPSfcDBrba77hS?= =?us-ascii?Q?VovVmU7hclAQfVT+bJasG14t7tg5Gz0A3ATGmJo200PY3SOFcLnjHg5wVW2N?= =?us-ascii?Q?oaxqiAWsQO7M5+PObYvCBD8HEA5JJLSwFjze2p+nFdWuFP3dL6/Ok7FpRbTh?= =?us-ascii?Q?rkxKZktzdfJlRstW6lScRvtUvUJHy6lyThF/OEyp2Tt8cxF3AQAEhQkXRPtY?= =?us-ascii?Q?6oqu5q+EGaYk7EgY1XU+YcFKIU3rgkxZKabVqBEqjfnv9tAKUuJcX3ejdmh9?= =?us-ascii?Q?vV2Y4lecxOozuJUFss/JGfjW4Al+Pexn9Zji9/DAemFNwzMc1xuOtY0SENFH?= =?us-ascii?Q?m6uR1QEiijLlUEd4cToKyvcl+GK6WbwnQX2f+0b3rCARlRKvQQrd4QU1+bB+?= =?us-ascii?Q?JK0F3hosf9r1nI7M4Ycceq6sSSr8uBNWu2FLvxU5LBq3hj7cUUNmDRKtXOFG?= =?us-ascii?Q?G2M3C14cgLd6RDJEAtTXgLQ976fX2QL8Tnv5m9PqPI1nCfdYMOuXa3IbRUA5?= =?us-ascii?Q?iA7U7Y4LJIDbropVgvEGudDd1oksjX7pDGKDysbwuFrLgC496irtWa1fMEVk?= =?us-ascii?Q?ols8V56YLYVDT1ZDiGI2t8LyhclwOuitkp+n+p8KVrO1wTzBMW5drbDIlJSS?= =?us-ascii?Q?hA/9xQTMxt1kgpekBTizDRzo8uhrlC1+xT4jPlI2IYDKRNwxpz04g6Mwg1VB?= =?us-ascii?Q?FE86mSJVpL8ZNHWpmbh0wSFu2vrmuHI3t9OWJb70d1TSHBVnaEO5rQWT4rmO?= =?us-ascii?Q?vaJG+ZM+tayO8dARHh2OObhY+YGH8wJreroOtOmKANVg5hV7uRdvjiAOXlzt?= =?us-ascii?Q?YVDNhX0GQBonvd9oYhmVjIv9C7+Rst5Mdni4Igs96qjLax9mz3fPs27qJ/g2?= =?us-ascii?Q?Lggmx362yOCYQZeU6pXZzD3dDA4epCAZlgoIi90fPvcF4uT3z4juYgMx9mcW?= =?us-ascii?Q?88lEbRg3U5JWxA85NiteDAQtKpWu/gVY0zDuOlff1EzPO9yN9a1Tkf9aCPBO?= =?us-ascii?Q?pppvl2fFYXRRHzVtkEVU6ynzK48KYpZpmwgahO1jStx0I3d5SgrbL2oNSNhH?= =?us-ascii?Q?6ZgJGHoa9Dt+TtC2D1zzgxXZAP4WIePjnV01KXp3dkdD/8oWkat1f3siuJaZ?= =?us-ascii?Q?P14LKC/UDFP63aVS50Q9XLthV2+jZjIy84VF4oIU+8JALjceXrn3h3s9oFUm?= =?us-ascii?Q?eJwWbPpkg3XmOy3a5Q3Tf/wOOtI0qhk2jhY3KfcQwyeKiZODOFP8yzCJ7Iva?= =?us-ascii?Q?piE+8A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB5013EAB350241249E7E738079F6A9PH0PR11MB5013namp_" 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: 6dfe46a4-a242-43d7-cede-08d9b643e54e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2021 10:01:37.4532 (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: DPJ+j0liexD0aQvj7/pLF0vJAD5c2QoGuO7SCkjuPZWwqWvHQfXpjgK4QNX1cSsCVG8zeITJOV+XQHuCZORd3CpU2G2EjVcE+1gfx0znC+4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5817 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_PH0PR11MB5013EAB350241249E7E738079F6A9PH0PR11MB5013namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. - 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. --_000_PH0PR11MB5013EAB350241249E7E738079F6A9PH0PR11MB5013namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

-        &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.

--_000_PH0PR11MB5013EAB350241249E7E738079F6A9PH0PR11MB5013namp_--