From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 55F1B45A58;
Wed, 9 Oct 2024 03:03:19 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 41236402B3;
Wed, 9 Oct 2024 03:03:19 +0200 (CEST)
Received: from NAM04-DM6-obe.outbound.protection.outlook.com
(mail-dm6nam04on2085.outbound.protection.outlook.com [40.107.102.85])
by mails.dpdk.org (Postfix) with ESMTP id 1078D4025C
for <dev@dpdk.org>; Wed, 9 Oct 2024 03:03:17 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=MlS2H9V6k5B+q0QEzrSnHyu/clcdpxENZG6l8BanqzhMm10oWDd3uy3wovH+R8U5btGF0U1zPVBKhZseWRKUCMEM4LOzzP6xCZwQR6dgTRYkjLkBN+9HBo/JDwyIUYaQihyuqsw0vAxka9BWQlVixEIkQwTgNdNbLHI8UbbN2ySwD3Qwc7iRuslfPOcOHTqKYevDFshkdX0zYU4FcOlfrz5bbVMfBncOUWVmQLeNMOVEMuW6KaqtLDTt7SKt8S4gbWhwyqbIyRkpIB8votjSKGQ5sU7G6Aj+3NrE+cBB1Vcc3dxGV4xZNUBstmyIDAsWif4y2S2Kb5hbvL1LGtFGuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
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=jKMXJ4+nRW1XLTq3Pi9p7IWefQSnt6+Z3pxEq0svfDI=;
b=mKVakC301p+Ms/AAV1KKVTIPccXxH+6FX61Rq4/PGqxjELgXDJuPULfaVCc6oK5t0xnqx9RnGkDM20i+6fPr2F6Az9vJ5d5qIyhoT9ZdtR1XzqLk+zsue6b7vOFqvMiIUrTgEpyfvm/yG4E5xRwLfg4gW6cRGyVSefb2BIdV/Mj5X+DkDM/w0/Q4zBTSqQVugB6ym/WS5LsiHYEKPR36G2syYg4+6sE/NW4xyXQQ1bA7QPTiw5rJRDG4YN+W0/eLfmtuus3J+WVWzxVE67Ea0oY5VVDmhHYAc8eR0x1b0jREs+fz3DP8DDU9OE+HAyyEQ2tNh4bCAc/QjgLdNhNlmA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=jKMXJ4+nRW1XLTq3Pi9p7IWefQSnt6+Z3pxEq0svfDI=;
b=EsSZZR6x2qGxDS+gtyi3OqO/0RrEJi6RolUdL45qt9olRV8IZnBe8PVZ+6ds5ofC59AWSrPhsfj+TFNwcu57DheFcWOGjHkJy4e2WMy8DzFYyqlpJKu0iw1z3wP3YcA3KNW23UxrMAD3qbzwfD29T3X4yjNmUGnDNZ6O6W4+BjY=
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=amd.com;
Received: from SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9)
by SA1PR12MB6920.namprd12.prod.outlook.com (2603:10b6:806:258::5)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.22; Wed, 9 Oct
2024 01:03:12 +0000
Received: from SJ2PR12MB8830.namprd12.prod.outlook.com
([fe80::c3eb:df02:eaa9:2055]) by SJ2PR12MB8830.namprd12.prod.outlook.com
([fe80::c3eb:df02:eaa9:2055%4]) with mapi id 15.20.8026.020; Wed, 9 Oct 2024
01:03:12 +0000
Message-ID: <b6b839de-1580-48a5-a705-cf06cbae928e@amd.com>
Date: Wed, 9 Oct 2024 02:03:07 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 1/3] net: add thread-safe crc api
To: "Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
"Marchand, David" <david.marchand@redhat.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Ji, Kai" <kai.ji@intel.com>,
"Dooley, Brian" <brian.dooley@intel.com>
References: <20241001181150.43506-1-arkadiuszx.kusztal@intel.com>
<20241001181150.43506-2-arkadiuszx.kusztal@intel.com>
<31a2db2a-1983-479e-ab96-5609cf9c18bb@amd.com>
<CO1PR11MB50091ED27301D0963CA803039F7E2@CO1PR11MB5009.namprd11.prod.outlook.com>
Content-Language: en-US
From: Ferruh Yigit <ferruh.yigit@amd.com>
Autocrypt: addr=ferruh.yigit@amd.com; keydata=
xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9
4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J
eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg
B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9
RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ
N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ
vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S
3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum
CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA
XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln
aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID
AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK
Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3
tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU
58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs
cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD
VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg
Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc
GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV
gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW
VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD
DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG
CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe
WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi
6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl
90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv
VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA
fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr
ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC
IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk
1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak
oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq
b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ
Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX
W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW
honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA
g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn
GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ
NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs
SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe
cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH
dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk=
In-Reply-To: <CO1PR11MB50091ED27301D0963CA803039F7E2@CO1PR11MB5009.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: LO4P123CA0318.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:197::17) To SJ2PR12MB8830.namprd12.prod.outlook.com
(2603:10b6:a03:4d0::9)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|SA1PR12MB6920:EE_
X-MS-Office365-Filtering-Correlation-Id: 3e267dbe-11da-4f5c-1bdb-08dce7fe25c6
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?bWVWb3llQU4wMFcwTU5XRnJLYmovbkk4bnIyUEVTNEZNUit2WjN2VGx5ZlNT?=
=?utf-8?B?ZjFNSkFsQjhwVEx6bzRPaVlxbjR2R1RUa3YxaWpDZDFaMXJnSjBzVVlZcFFx?=
=?utf-8?B?VUpCZ0Yxcm04aWUrSnZMVmNtUklEdURhTk9EZDZ6SDB3cDY0THBkRkRtblg1?=
=?utf-8?B?U203MDVKd2hzallaT2NpOVV6Yi9mckRaakxrYVBibWJrbGdtbC91YWswRjdx?=
=?utf-8?B?RlBTY084UnpYU1NZWmU2ZkxLL1lWR05SWkdYTVFjSWhHc0hqcTYwYmNVeVkx?=
=?utf-8?B?UU1Jdm1DcmpBbkpWU0UrL0pUWG5pUXd6YWM4b2tOaytJSFBwTS96SUxvTkhs?=
=?utf-8?B?UE1seVd0RGU4V3AyTVBNOEg1bHl3amRFdUNWQmlicGYvY1hDY05QRFBwZFBm?=
=?utf-8?B?YVZiMGdpNEFyOW1iL2hzS3dReDZRNHcyZE9ITlQ2eS9jR1ZYMllkTXZVcjBL?=
=?utf-8?B?SFdZV1RpVHFBajNnSzRLUlp0b0ZzQnlRYUdDL3Jib3dIUHlNczhQTjFvVjFV?=
=?utf-8?B?WFN0RWJEaml4R2JvR2VnVE5NZUxqaEtiSmNhc01PL0NMRk0zQXVZVG1FYXRs?=
=?utf-8?B?a3crRUN0dEkxKzRJRHVROFI4VGMzd1hmZTYyL1R2NFhpRXRoVXpUSmRtVjJ1?=
=?utf-8?B?UTJpUkIrT3JiYU9Sbno4V0NqUHE2a2piN3lac2duZkR6TW5IT0t1RmRMNEMx?=
=?utf-8?B?ZW1JeFQ5Ly9EcjNEWlpxOEs3cUN1Z3d0bTVlaWQ5bWw4cHF2Y2lkSllLVTNx?=
=?utf-8?B?Q0tXamRsSUdvWlAycUgybUIrUWhDZ0h4V3A1ZDJoUFVlNlRTbktQZmtIK1BS?=
=?utf-8?B?YUhoM1lFejBLcDVkS1BLcjRJU0gzTVVFZUV4WVZRMkNFTkhEMWtyYUVaS2pm?=
=?utf-8?B?M2RsbDg5UkRLMHllVVo2a2lKUzJGZUhBejVWUS9CeGU5T2NTYno5RElCQmZo?=
=?utf-8?B?enVaQ0hWdmg3YXdGVTIrVXZHZjVpMmluTjI3OTVyWGlJUm0ySkZQUm84ajVT?=
=?utf-8?B?OEtTbkdiWmE4NHo5VzRkUi9meGY4U0UybERoU3FHWmMxNGJFbGFyNlhpc3V4?=
=?utf-8?B?ejRhUGl2Slgyb0Q1cmRGcnhkSTZhMys4cjJHQXpMTnVGVzBybElmdzBpZUp6?=
=?utf-8?B?OU1XTGkrdEJmQmFhakhBYVZzclhjMjYwdGVyQlhYQUpiZ1dMRFNVaitib3Ru?=
=?utf-8?B?WDlFUll5NWx0UFVGd0hvU01wV1hpbldMbWVDSnhVcS8xZlFYeDV5U2lFT3ox?=
=?utf-8?B?aWE5b1J1bDZqemJSSVE2eXJOSUhpUEg0cHhycXFHRGhRZWNpMjhIb2N6ZXov?=
=?utf-8?B?V05VNmZ3MmtDbGZER1MyYWNUTWhSc3lGZGtseElVMUYxRXphSGJZbWFRdHlT?=
=?utf-8?B?eFpiNndTSlphYUVrMVQxRFZ5YWpVYzRhQVgzbmtBaG43N1FyMnZ6YnhRTnBQ?=
=?utf-8?B?YXh6QmVxTWkzMDlYRSswaUFCNTdsNG4wTy9wRHZxeTF1Q201Yk1zRnE3MFJk?=
=?utf-8?B?ZDhwalVFWmJDSGdlTS83c01Vemd3Y0xsVmJpTDJHb2c2SnBuUlpCN3dENUp2?=
=?utf-8?B?QlhBdWgrSml2Sy9NZUZKak9tcy9kUTAxeEc5eDJCdWFweWFXQ3BXZSszQWZD?=
=?utf-8?B?MzBCR3d0aTNjUmgvS3loRUVCdXg3MUVMdGF3anRtNWRKMGxsUHVOUUdqa3hE?=
=?utf-8?B?NHdhYm5GUVJyNml0djRGaStybDRTQ1JNWHR0WktlVmNGOE9IMXJTdFZ3PT0=?=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:SJ2PR12MB8830.namprd12.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230040)(1800799024)(366016)(376014); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UFgrdlZ2bmFiVHAzN3loNDQvMi96Z3M0aUdXbEpmaUdsc1dFcnJQcDFiRjVU?=
=?utf-8?B?aWR0VGdXYmQyZ09jOFNFODRyZ3BGVVIxdE5vZ1k1V2srMGVSUEF6R05MeU5W?=
=?utf-8?B?SHFCbUhlcUs2eTZLMHdRVlovQmNFQ01OMS9ta3ZrN0VHMkhMN3VrbUNtQUdL?=
=?utf-8?B?N1FNNW1DRE1sZnlKTFIxYXNmTGV1Q0RoSWdCaHhURjBwcllCbU5hcmdDTUt6?=
=?utf-8?B?RnN2S21kYkdEaDJsZ05EVXRNSndpcFRBeUNVa3ZrYlpidzR4blpMcDZ5bzZz?=
=?utf-8?B?Y0tyUzNjbTN5T2pidkkzYmVSNlFTSEk2ZXZhaS8vNXJ3QUNmSW9ONHIxTmVN?=
=?utf-8?B?VytCcWYyYlk3alJLalR0c25FMzZkTW5zczAvQ3NacHMxcmxZR2tpNEFSamE4?=
=?utf-8?B?WG5LY3BxcDdHZ0Y1Q3ZOSjJCcFUya1huQTRsTFA4UmdObmRlYWNkU09LRUVz?=
=?utf-8?B?OFVFL0FNdU8yeGRwS3lTNDBqQW5IN2h2aGpUM0d3aFBNaFRZSzQ4T3NmSTBs?=
=?utf-8?B?czFwa2hMUkpsU2RxRmJLVkhxMWRxZS9Kd2piVGxPR0VIb3gxdWZaM3pEbE9T?=
=?utf-8?B?Y3lqMDNtTTVhNVIxbytpeDVnd0ZLYzhzL2JLOEllRE1VT1NkMFd5emZpZTM0?=
=?utf-8?B?SGFvR01hY0NZamphdjhHNzZVbG9ReVl1RENLcjZYc2JTZzlMMHFpWnN1bmM3?=
=?utf-8?B?VGV3bUVoZE80bUdpWDFtNmMwanRWNnA1ck9leVBUQWt4ZkZjRE9ESkRXcTVi?=
=?utf-8?B?dnJjY3FLUWVrTWd1eVg2Y2wrQm8vYVRYbFFUTDNWRFgxTHR2ai9YUjBpcGcx?=
=?utf-8?B?Z3NHYW9STDdEV0NkQjdxSkJsd3FoLzFZT25UMmFOS3kvWWtYSW9CcDFkNitU?=
=?utf-8?B?YTQzcVpjeWZXWkEyeEVqU1dDSS9vOVdCWnVWUlRmL0NIN1AvWjlzUkwvazhO?=
=?utf-8?B?UmZDRVYvVVhwazZ3dU1RY1NlYU5UK0JKZmlablhyU1pub2JRWXlmUlJaM0N1?=
=?utf-8?B?cjVDR0l4VTJtRldLREhjMStDc1h3WE1TMytYWDh3S0JTVDlPeE1pbXR4QVlt?=
=?utf-8?B?SnQrb1RhcjZNWnAzM1BDVzF1cTYwZG1YK1psbXhBZ3VQb09xNktVZ2dXR29P?=
=?utf-8?B?Q3BZU0hLcTM4dnV6S1I3aEg1aDlkeEhmV2lrWHNXMWkxTERUeU9vd3RJVFBG?=
=?utf-8?B?ZVo1eVAwWWtVRVpBQWRseXQyZVMrWEJrS2FDdjNpYlEydWt5eUJTalpGVnly?=
=?utf-8?B?ZTB0NjdHQ0pHemRNdHpqTlAralhTUzhjNHNscENNZmhwUkhOTXMzbzZkcVI2?=
=?utf-8?B?d2txWHZSVlZXeHJhVGxIUXJrcUtzUmFLTXpZS3RON0VkODJxYUtCTWd4YVJs?=
=?utf-8?B?a3JENUloZlU5T3ZLemFZd3B4SzZlVSs3N2t6WEZEMmIzaEdBcDhjM0tlVnZU?=
=?utf-8?B?ZHJIRnU3TXVPRXpFUkZTV2U1Q3poTTcwaWF6bE5OK2ZacVM3L1JZUGJCSWJM?=
=?utf-8?B?QVhhVzJrRStlVnF2NHJVczNUY0dwdFdlQUFZNzFRRzErOFhPVXN2VGozdTZl?=
=?utf-8?B?UlJtZ1BUaW1leE5OV3JBbWRhUzBrR00vc29KbnFzM2I3MVN0dmxDVnBtYVNz?=
=?utf-8?B?aHYvTUJqOWpoUWpHcTdhcDRjM2RYRStlUEZuT0ppK0JKY2ZuakxhbjhaY2pF?=
=?utf-8?B?V1FyaGhWT053NTVCamh5UEZiWlJTbFpyNytuM25Qc1FJNVZzb2dyOXo1ZVl5?=
=?utf-8?B?WDZzMWdEcHJYaU5VUFFTbVZORG5LTkI5aWNhN0VXL0JaVzFwTWxYUkpWaFM4?=
=?utf-8?B?ZTZnVXpTd1dpM2NUZm5ERnlWenJNRHc2SmtXUkwweCtEd0d4TkZPaTcrT1NM?=
=?utf-8?B?RG9EclZzdC9jelR4M3BRSEszNUVLdmptaG9OSm95ODUxc240TE1YV21XM2lT?=
=?utf-8?B?QS85Tk5nakZXUkZRSER1N3ZxRVJsTUEzMlBCcWt1ZlFwZnRteWMwMWlZbk5E?=
=?utf-8?B?Z3dZSFpyMjNLVHhMMzhJQjlISERDUkJTTWVKVHQ3YjhOczJFMk5rNmNjSGky?=
=?utf-8?B?SlhCTGFPZnhjWUw1Q2J4L3A3NnBOWUJ2WitwMElxOSsreHVuRklWUzN3Tjl1?=
=?utf-8?Q?hbBstq5VqjqGUKpQgn9VdBVEG?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e267dbe-11da-4f5c-1bdb-08dce7fe25c6
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2024 01:03:12.3416 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 0YV2g5TlSvl6nl3J+M5xi62uIKP80fD4CnEvqeK1lNg/Qe0sJBRMHp6z873ciKLM
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB6920
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On 10/8/2024 9:51 PM, Kusztal, ArkadiuszX wrote:
> Hi Ferruh,
> Thanks for the review, comments inline,
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>> Sent: Tuesday, October 8, 2024 5:43 AM
>> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Marchand, David
>> <david.marchand@redhat.com>
>> Cc: dev@dpdk.org; Ji, Kai <kai.ji@intel.com>; Dooley, Brian
>> <brian.dooley@intel.com>
>> Subject: Re: [PATCH v2 1/3] net: add thread-safe crc api
>>
>> On 10/1/2024 7:11 PM, Arkadiusz Kusztal wrote:
>>> The current net CRC API is not thread-safe, this patch solves this by
>>> adding another, thread-safe API functions.
>>> This API is also safe to use across multiple processes, yet with
>>> limitations on max-simd-bitwidth, which will be checked only by the
>>> process that created the CRC context; all other processes will use the
>>> same CRC function when used with the same CRC context.
>>> It is an undefined behavior when process binaries are compiled with
>>> different SIMD capabilities when the same CRC context is used.
>>>
>>> Signed-off-by: Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
>>
>> <...>
>>
>>> +static struct
>>> +{
>>> + uint32_t (*f[RTE_NET_CRC_REQS])
>>> + (const uint8_t *data, uint32_t data_len);
>>>
>>
>> It increases readability to typedef function pointers.
>
> Agree, though this typedef would be used here only, that’s why I left it out.
> But I can add it then.
>
>>
>>
>>> +} handlers[RTE_NET_CRC_AVX512 + 1];
>>>
>>> -/**
>>> - * Reflect the bits about the middle
>>> - *
>>> - * @param val
>>> - * value to be reflected
>>> - *
>>> - * @return
>>> - * reflected value
>>> - */
>>> -static uint32_t
>>> +static inline uint32_t
>>>
>>
>> Does changing to 'inline' required, as function is static compiler can do the
>> same.
>
> True, though it may be more readable sometimes.
> Of course there is no way that in O3 these functions would not be inlined by the compiler, regardless if the inline hint is present or not.
>
>>
>>> reflect_32bits(uint32_t val)
>>> {
>>> uint32_t i, res = 0;
>>> @@ -99,26 +43,7 @@ reflect_32bits(uint32_t val)
>>> return res;
>>> }
>>>
>>> -static void
>>> -crc32_eth_init_lut(uint32_t poly,
>>> - uint32_t *lut)
>>> -{
>>> - uint32_t i, j;
>>> -
>>> - for (i = 0; i < CRC_LUT_SIZE; i++) {
>>> - uint32_t crc = reflect_32bits(i);
>>> -
>>> - for (j = 0; j < 8; j++) {
>>> - if (crc & 0x80000000L)
>>> - crc = (crc << 1) ^ poly;
>>> - else
>>> - crc <<= 1;
>>> - }
>>> - lut[i] = reflect_32bits(crc);
>>> - }
>>> -}
>>> -
>>> -static __rte_always_inline uint32_t
>>> +static inline uint32_t
>>>
>>
>> Why not forcing inline anymore?
>> Are these inline changes related to the thread-safety?
>
> O3 will inline it anyway, and with always_inline it will be inline even in debug mode. I just see no reason forcing it upon the compiler.
>
>>
>>> crc32_eth_calc_lut(const uint8_t *data,
>>> uint32_t data_len,
>>> uint32_t crc,
>>> @@ -130,20 +55,9 @@ crc32_eth_calc_lut(const uint8_t *data,
>>> return crc;
>>> }
>>>
>>> -static void
>>> -rte_net_crc_scalar_init(void)
>>> -{
>>> - /* 32-bit crc init */
>>> - crc32_eth_init_lut(CRC32_ETH_POLYNOMIAL, crc32_eth_lut);
>>> -
>>> - /* 16-bit CRC init */
>>> - crc32_eth_init_lut(CRC16_CCITT_POLYNOMIAL << 16, crc16_ccitt_lut);
>>> -}
>>> -
>>> static inline uint32_t
>>> -rte_crc16_ccitt_handler(const uint8_t *data, uint32_t data_len)
>>> +crc16_ccitt(const uint8_t *data, uint32_t data_len)
>>> {
>>> - /* return 16-bit CRC value */
>>>
>>
>> Why not keep comments? Are they wrong?
>
> Functions names are very self-explanatory, that’s why I dropped comments. I can add comments if needed.
>
I am for restricting changes to the target of the patch which is making
CRC calculation thread safe, unless code changes invalidates the
comments, lets keep them. Same goes with inline related modifications.
>>
>> <...>
>>
>>> +static void
>>> +crc_scalar_init(void)
>>> +{
>>> + crc32_eth_init_lut(CRC32_ETH_POLYNOMIAL, crc32_eth_lut);
>>> + crc32_eth_init_lut(CRC16_CCITT_POLYNOMIAL << 16, crc16_ccitt_lut);
>>> +
>>> + handlers[RTE_NET_CRC_SCALAR].f[RTE_NET_CRC16_CCITT] =
>> crc16_ccitt;
>>> + handlers[RTE_NET_CRC_SCALAR].f[RTE_NET_CRC32_ETH] = crc32_eth;
>>>
>>
>> +1 to remove global handlers pointer and add context,
>>
>> But current handlers array content is static, it can be set when defined, instead
>> of functions.
>
> Can do it for scalars, but for SIMD there is this runtime check like this:
> if (AVX512_VPCLMULQDQ_CPU_SUPPORTED) {
> So compiled binary on AVX512 machine could filter it out on the machine which does not support it.
> There is no NULL check in crc function so it would not change much when called -> Invalid address vs Invalid instruction.
> There are not many checks there, as this is CRC after all, it should be a small as possible, yet probably NULL check could be advisable in crc function then.
>
There is already AVX512_VPCLMULQDQ_CPU_SUPPORTED etc checks in
'rte_net_crc_set()'.
So does it work to update 'handlers' statically, without condition, but
have conditions when use them.
>
>>
>> <...>
>>
>>> -static uint32_t
>>> -rte_crc32_eth_default_handler(const uint8_t *data, uint32_t data_len)
>>> +struct rte_net_crc rte_net_crc_set(enum rte_net_crc_alg alg,
>>> + enum rte_net_crc_type type)
>>> {
>>> - handlers = NULL;
>>> - if (max_simd_bitwidth == 0)
>>> - max_simd_bitwidth = rte_vect_get_max_simd_bitwidth();
>>> -
>>> - handlers = avx512_vpclmulqdq_get_handlers();
>>> - if (handlers != NULL)
>>> - return handlers[RTE_NET_CRC32_ETH](data, data_len);
>>> - handlers = sse42_pclmulqdq_get_handlers();
>>> - if (handlers != NULL)
>>> - return handlers[RTE_NET_CRC32_ETH](data, data_len);
>>> - handlers = neon_pmull_get_handlers();
>>> - if (handlers != NULL)
>>> - return handlers[RTE_NET_CRC32_ETH](data, data_len);
>>> - handlers = handlers_scalar;
>>> - return handlers[RTE_NET_CRC32_ETH](data, data_len);
>>> -}
>>> + uint16_t max_simd_bitwidth;
>>>
>>> -/* Public API */
>>> -
>>> -void
>>> -rte_net_crc_set_alg(enum rte_net_crc_alg alg) -{
>>> - handlers = NULL;
>>> - if (max_simd_bitwidth == 0)
>>> - max_simd_bitwidth = rte_vect_get_max_simd_bitwidth();
>>> + max_simd_bitwidth = rte_vect_get_max_simd_bitwidth();
>>>
>>> switch (alg) {
>>> case RTE_NET_CRC_AVX512:
>>> - handlers = avx512_vpclmulqdq_get_handlers();
>>> - if (handlers != NULL)
>>> - break;
>>> +#ifdef CC_X86_64_AVX512_VPCLMULQDQ_SUPPORT
>>> + if (AVX512_VPCLMULQDQ_CPU_SUPPORTED &&
>>> + max_simd_bitwidth >= RTE_VECT_SIMD_512) {
>>> + return (struct rte_net_crc){ RTE_NET_CRC_AVX512,
>> type };
>>> + }
>>> +#endif
>>> /* fall-through */
>>> case RTE_NET_CRC_SSE42:
>>> - handlers = sse42_pclmulqdq_get_handlers();
>>> - break; /* for x86, always break here */
>>> +#ifdef CC_X86_64_SSE42_PCLMULQDQ_SUPPORT
>>> + if (SSE42_PCLMULQDQ_CPU_SUPPORTED &&
>>> + max_simd_bitwidth >= RTE_VECT_SIMD_128) {
>>> + return (struct rte_net_crc){ RTE_NET_CRC_SSE42, type
>> };
>>> + }
>>> +#endif
>>> + break;
>>> case RTE_NET_CRC_NEON:
>>> - handlers = neon_pmull_get_handlers();
>>> - /* fall-through */
>>> - case RTE_NET_CRC_SCALAR:
>>> - /* fall-through */
>>> +#ifdef CC_ARM64_NEON_PMULL_SUPPORT
>>> + if (NEON_PMULL_CPU_SUPPORTED &&
>>> + max_simd_bitwidth >= RTE_VECT_SIMD_128) {
>>> + return (struct rte_net_crc){ RTE_NET_CRC_NEON, type
>> };
>>> + }
>>> +#endif
>>>
>>
>> Is it more readable as following, up to you:
>
> Agree, I will change it.
>
>>
>> ```
>> rte_net_crc_set(alg, type) {
>> enum rte_net_crc_alg new_alg = RTE_NET_CRC_SCALAR;
>> switch (alg) {
>> case AVX512:
>> new_alg = ..
>> case NEON:
>> new_alg = ..
>> }
>> return struct rte_net_crc){ new_alg, type }; ```
>>
>>
>>
>>
>>> + break;
>>> default:
>>> break;
>>> }
>>> -
>>> - if (handlers == NULL)
>>> - handlers = handlers_scalar;
>>> + return (struct rte_net_crc){ RTE_NET_CRC_SCALAR, type };
>>> }
>>>
>>> -uint32_t
>>> -rte_net_crc_calc(const void *data,
>>> - uint32_t data_len,
>>> - enum rte_net_crc_type type)
>>> +uint32_t rte_net_crc(const struct rte_net_crc *ctx,
>>> + const void *data, const uint32_t data_len)
>>> {
>>> - uint32_t ret;
>>> - rte_net_crc_handler f_handle;
>>> -
>>> - f_handle = handlers[type];
>>> - ret = f_handle(data, data_len);
>>> -
>>> - return ret;
>>> + return handlers[ctx->alg].f[ctx->type](data, data_len);
>>>
>>
>> 'rte_net_crc()' gets input from user and "struct rte_net_crc" is not opaque, so
>> user can provide invalid input, ctx->alg & ctx->type.
>> To protect against it input values should be checked before using.
>>
>> Or I think user not need to know the details of the "struct rte_net_crc", so it can
>> be an opaque variable for user.
>
> I would love it to be opaque, but then I would have to return a pointer, which then would involve some allocations/deallocations and I wanted to keep is as simple as possible.
> So probably the checks would be a way to go.
>
True, +1 for simplicity.
>>
>> <...>
>>
>>> -/**
>>> - * CRC compute API
>>> - *
>>> - * @param data
>>> - * Pointer to the packet data for CRC computation
>>> - * @param data_len
>>> - * Data length for CRC computation
>>> - * @param type
>>> - * CRC type (enum rte_net_crc_type)
>>> - *
>>> - * @return
>>> - * CRC value
>>> - */
>>> -uint32_t
>>> -rte_net_crc_calc(const void *data,
>>> - uint32_t data_len,
>>> +struct rte_net_crc rte_net_crc_set(enum rte_net_crc_alg alg,
>>> enum rte_net_crc_type type);
>>>
>>> +uint32_t rte_net_crc(const struct rte_net_crc *ctx,
>>> + const void *data, const uint32_t data_len);
>>> +
>>>
>>
>> As these are APIs, can you please add doxygen comments to them?
> +1
> I think this change could be deferred to 25.03.
> Adding this API without removing the old one should be possible without any unwanted consequences?
>
This is not a new functionality but replacement of existing one, so it
will be confusing to have two set of APIs for same functionality with
similar names:
rte_net_crc_calc() and rte_net_crc()
rte_net_crc_set_alg() and rte_net_crc_set()
Also there are some internal functions used by these APIs and supporting
both new and old may force to have two version of these internal
functions and it will create complexity/noise.
As this release is ABI break release, it is easier to update APIs
(although deprecation notice is missing for this change).
As an alternative option, do you think applying ABI versioning in 25.03
works for these APIs?
If so, old version can be cleaned in v25.11.
> I still have some second thoughts about this max-simd-width. DPDK does not impose any restrictions on this parameter in the multi-process usage,
> there may be some room to alter some things there.
>
>>
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> diff --git a/lib/net/version.map b/lib/net/version.map index
>>> bec4ce23ea..47daf1464a 100644
>>> --- a/lib/net/version.map
>>> +++ b/lib/net/version.map
>>> @@ -4,11 +4,25 @@ DPDK_25 {
>>> rte_eth_random_addr;
>>> rte_ether_format_addr;
>>> rte_ether_unformat_addr;
>>> - rte_net_crc_calc;
>>> - rte_net_crc_set_alg;
>>> rte_net_get_ptype;
>>> rte_net_make_rarp_packet;
>>> rte_net_skip_ip6_ext;
>>> + rte_net_crc;
>>> + rte_net_crc_set;
>>>
>>> local: *;
>>> };
>>> +
>>> +INTERNAL {
>>> + global:
>>> +
>>> + rte_net_crc_sse42_init;
>>> + rte_crc16_ccitt_sse42_handler;
>>> + rte_crc32_eth_sse42_handler;
>>> + rte_net_crc_avx512_init;
>>> + rte_crc16_ccitt_avx512_handler;
>>> + rte_crc32_eth_avx512_handler;
>>> + rte_net_crc_neon_init;
>>> + rte_crc16_ccitt_neon_handler;
>>> + rte_crc32_eth_neon_handler;
>>> +};
>>>
>>
>> +1 to David's comment, these are used only within component, no need to
>> export.
>>
>