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 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 ; 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: 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" , "Marchand, David" Cc: "dev@dpdk.org" , "Ji, Kai" , "Dooley, Brian" References: <20241001181150.43506-1-arkadiuszx.kusztal@intel.com> <20241001181150.43506-2-arkadiuszx.kusztal@intel.com> <31a2db2a-1983-479e-ab96-5609cf9c18bb@amd.com> Content-Language: en-US From: Ferruh Yigit 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> Sent: Tuesday, October 8, 2024 5:43 AM >> To: Kusztal, ArkadiuszX ; Marchand, David >> >> Cc: dev@dpdk.org; Ji, Kai ; Dooley, Brian >> >> 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 >> >> <...> >> >>> +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. >> >