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 1F18E45AF0; Wed, 9 Oct 2024 11:11:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B39FF40E32; Wed, 9 Oct 2024 11:11:41 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2057.outbound.protection.outlook.com [40.107.223.57]) by mails.dpdk.org (Postfix) with ESMTP id 2C8F440653 for ; Wed, 9 Oct 2024 11:11:40 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kmE/G7XMHykxcFozcyU039cwgbSm96PnHQL76ViK5OB/K6ujpBhw0JpMsBoT+ynPAXmr1lMIrzDA+XAPZP6GgDhWk/Ovdk1BdO9czogQc8kfgyx1tE8pQCoJMbvR8uZiL8qck4DTfTGnlAflhbahTZNtfqyKTNRTZPfMlcrqq50Ux7n66gtShoP8gXXve3Tci/uP3Sbd163ez0kPArD7j3Dhop/eUtqmOQvJ3ezgccDuawRarM5RHTQvEBH8OQxGJtyxCbkN1eBBth03XgZOas9/+QIEbIWk7fojjnCCg6Ojfarc3CSLzeFdBzWgvj8JltgHUJ7WsDHnHJw1+x7lHA== 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=aO2JKEh9py8L5xgbO5dj/OMl3/J8b+L5E9dsoK/ooX0=; b=P5U9uUvyNEukto1Nj6stat9khzx4weAW+pbvkH8dyCjZZPWoZYyA6bxe/SZxB+wQZihxjJOI47NySO1OvtXxPW6P5BB2XRFsP84ALvPDEVyAi/04RzzyvDMzdaikPE/9JKPp9Nb/xeQpK4S4DO9Lhln6CnR7oefBYpi9/ZlVgJqBslMMNjQFPOBtbQ1g8ige1k6haXwK4FCCfAhKgO/5TYkkjvw5jtf1FbxadZu9NtWAJMZjea91XgnbIxFbFNE/qm4szteqYjJ/M8WQH/nXsp072PLQWzOdQAWyZ+FLk+OHDniPj1CKKuWOyGclyMCMCwEw/v88Kb83HZBzVpXh5A== 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=aO2JKEh9py8L5xgbO5dj/OMl3/J8b+L5E9dsoK/ooX0=; b=A+40ju9EoJo4ss9ilSVfibcXWwy6umRKX0+0y5TMpRfYxEivz8FaFtw0ZtUVjdsaCdP/Vf6y5bPopKwowB0SdE5kpAShdEYiXz3k7wZALC6X32XNkOhcRNhldwJzbTCKRZ8ke6JcbjMd2OUIC47dvI8SxGclspgGAaqKuLA/ne0= 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 DM4PR12MB7621.namprd12.prod.outlook.com (2603:10b6:8:10a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8048.16; Wed, 9 Oct 2024 09:11:38 +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 09:11:38 +0000 Message-ID: <683c3a3d-0e02-46a7-9490-9efe759fa712@amd.com> Date: Wed, 9 Oct 2024 10:11:32 +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: LO4P302CA0037.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:317::9) To SJ2PR12MB8830.namprd12.prod.outlook.com (2603:10b6:a03:4d0::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR12MB8830:EE_|DM4PR12MB7621:EE_ X-MS-Office365-Filtering-Correlation-Id: 4ba06e4c-d137-45d8-a47b-08dce8426141 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?S0o3ckV1QTUyd2JCaXNEVXlQQ0cwdVdEZDRlMFVTNFZCSE01V1dQRzRUTmt1?= =?utf-8?B?eHpGUTA0aGJieSs2bmx0ck5PeFEwMVpGZ3hsNzNLcjMxbG1uM1UyeFcvR2dI?= =?utf-8?B?bVlpcVc5bTVhQ1Bwc1E4L1Y5WFRNeXg2cHJ5dGtJQXZxZnVoK1k4WmRqSnFl?= =?utf-8?B?djJVOXhITkM3OHVuTE9wSHREQU55clRMYjJZM3A4ZWJ5OXRFZjlXNTBQdEVk?= =?utf-8?B?OC9VWG9aeGVZMmpldzV1Zld5ZlFpblY0YjF0RGNJbythV2djOG1RYmFDY0Jz?= =?utf-8?B?M0QvbDhFRnFjenNPa2ZMYVY5S3RpZjhqWFBOZ09iYnA4Ky85NVZsZFF0czV2?= =?utf-8?B?ZmhuL1RDV3p2QUpWR0dWSGZIbDhYaDFDYUhPMEhaUmVGbXdjcjk3L2dnWlAr?= =?utf-8?B?VFVDNHZhZzlvQXhpOVBNVGJnVXpqNWUzcWt0V1M5dzBvaGxmYzlDeXhGeGZl?= =?utf-8?B?VS8zb25ZSzcwUUtETm9BemtqTjRwdm1EUDVwd3FqZFd4QU10RDRlNHRwZXV3?= =?utf-8?B?eE9FbnQ2aDNBd1N1L2JaL2x5YXhuZ25wbjVVWTVWY1JUU0R2MnRuZ200bWxM?= =?utf-8?B?ckJMeXZrdVo1MDdNd0RqUWZLZEdpaUw4VnhtNldoVC9KWnd1OGk5a1YrcjNa?= =?utf-8?B?NmhzT0hsd0M3Z2JtL0JlOWw4M1ZCVnVoUWZJNVR0QkdQLzRmVkQ4M0NDUjVM?= =?utf-8?B?OHZTS3pVYS95RW9kalVSa2FOZnBjTnZReHB1K2Y3b2g4UUhIdU9venVUZWUz?= =?utf-8?B?eEU2Rmd4V3BkUmtsYS9WR2x0eUpZRjRDU0RxZlNRcVJwTVdZMzh6ajBEejFm?= =?utf-8?B?NW9jdFlWcWtxMlRwb3pPT1JUczBBUHZKb0FaeXFUOWtINEx3R2EyNGR4alNX?= =?utf-8?B?UVNTZDJRWHcvOWZHbTBjeUN5MWNpWmhtb01ZRHFHWDJpZEJGdk5Pcmg0SGZu?= =?utf-8?B?L050QWZrK2J6cjRxL1BGSkE1anArcFQ2RTIyMFJxRHhRWHlGVjNleVBDRkdJ?= =?utf-8?B?eGxVNkM3Mkt3blVYREo3R0YzWEJxYUx3QVF3OG5zd2NLcjJTYlFRQlFJdm9t?= =?utf-8?B?Y25VOXZua2w3bVJSaVk2dFlXam5vY2wvMzMwbG9qd2VBVkJxd09UM0FTNTNa?= =?utf-8?B?bjVuMFhyb3hoMnRORnFkd1RpOFBvdVdBTGlPSkM2TkpwaHBzaTlMakczTUtn?= =?utf-8?B?Q2R2ZEx0QS85dTllbG9vODUxTmEvTjJ0YkJzdFFWLzJqcy9HU0FvR0FLVFhn?= =?utf-8?B?bXJ1YWdLT3BUZE4zOUhtMkg1M1hMMllMdnAwYTZCdzFQNEF4blRjMGpSTklF?= =?utf-8?B?T1RueWg1NzlHRmk3ZnBVRmFLU1lqcnhoMVBReDZmbithS1EvSTluV2t0TDU1?= =?utf-8?B?RitGUlZqNzBianJ0WEg4dmFxQS9BY2wyU1BCT0QvTXhsenpTN21kS0JjS0Z2?= =?utf-8?B?bDNvbVhHeWZFUGJrWjRFZkF5NnpnbVBKZFRyQ3cvbWZaakMyV3VuU25ua3kr?= =?utf-8?B?S2VKODRNdkNEbFJvYUlpTUJDZDVqaVA4dFpFWks1QTBYQi9mOFoyWThCWVJk?= =?utf-8?B?S2cyYjZBM0JjMmtpRENnSndQQ0FBbFU5RUlUaWVLcy9PdXdCQlpQTW5EMlJK?= =?utf-8?B?K1BFdldzNzZIdlBtK0twZE55bjZWUjRFcGZRS0piN1dNd0RaT1V6WklQR0FO?= =?utf-8?B?RzFNemE1L3o4QU4wVldjbGg3TnpvNmZvYVA0SnQyUU9mRTFRb1hJNzVRPT0=?= 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)(376014)(1800799024)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OHhDR21mYndSVWRhMUp4UjE5bVNiSTRCaGFXMUJKVmpWTUloK1lUZHU3WlhC?= =?utf-8?B?ZXlJQm84Y25HV0g2a2p4akVvNDd1TzBTSmpwcUdDSlVaRmZVZXZCYTkvc25P?= =?utf-8?B?TnAxNHVJbDhZSkh3SHloTjNtMGFsTEdPbmZDNzc1Mm9paXJMd1NRYlhSUnNI?= =?utf-8?B?dXhGVUFaMlAvVXZqakFrdGE5VlI5RnFRekEydzFsbSszcHBCeTJQMG5mRTli?= =?utf-8?B?dnF0OWt4S0p4LzNxZllWODhqZmpBWEZhVWJvUzNReE84NkIwSXNEUEJrY1cr?= =?utf-8?B?UVhaY0R5ZkkwOE9UK0VTY1FoREUwNVB6Rll4VThQTGtNWFM0bXRTZkZJblg2?= =?utf-8?B?dy9ObjljQklMeU9CKzIrTW1FOWtCRTBocythby9DemFLRXlUa3NndExPTmJC?= =?utf-8?B?cmk4eVZUcjBrQk41dnRtY1kwdUVzZmVkU3RYaHlwUFdPeEhhRU4vR0NQV1M0?= =?utf-8?B?Z1k2V1lrcEwzZXpRdzdWbkJpVUFPVWNockMxNlRJa01vbDNwbjE1bEI1RWxS?= =?utf-8?B?Z20xZzZyVXMrd2ZUcHdMSjBMOUYyZnREa2c3NEdTMmduekh4RlNCQXZtM2dh?= =?utf-8?B?U2JXeldPbnBtMHV4aGtuS0VCQ2xxQ3V0RUhFK1JxaXFBZ3dhYmlDY0ora0F4?= =?utf-8?B?ZlBxV3hPUklHS0VxQ1BzM2dISjV1bDUxQnNpSGVEQ09mUkdHZzhxRjlENy9F?= =?utf-8?B?OWV4K3ZGYmpYYUVpaG8xL3MzUEFBb0szOTN5U3gxOWxVYkFsOXlqNUFrYmtp?= =?utf-8?B?cGRJTnIyandUQXJqdTNlVW9GMzNWeGlaY0NDMDJXSE40WmJsOUZuMWFhMzhP?= =?utf-8?B?OGNrRFNXc09lNDJUVHQ3WlNFMG9hNzhGditSVDQrbGE5UFZ0d0xCWWZtMEpa?= =?utf-8?B?bzg2djh1azZXSVpyOWNTM2ZkRStYUmNnb2d3Q3dzdnd2OVVRU3NkSDdsSTcy?= =?utf-8?B?ZHRHbWg5bmdPTmVuWldTVC9lUFJxcTdVa3JZV0VTSjRqb21WSXFBZVdOQWJH?= =?utf-8?B?bVJqUWZDVFRGTk1ZTC9qdms3bzlMTjZNWThpOThUUURkQjFGZHE0ZHROaGNN?= =?utf-8?B?ekEyREVEalU5TGNYRng0cVduR09teFFsWlptUzdMZW9KcDZiNCtpUmlvYllv?= =?utf-8?B?aDBzemNkWDZMU3dHSldDV001WnFOR0U1YkgzelRFS1pBOHNNQUJ6N3NZSzlo?= =?utf-8?B?ME10T1U5Vi96N0tMdWhSOTlxdEVrS2VrRkxGcU9jay9uSURCaDlJREV0eHVt?= =?utf-8?B?cSs4QTJVcjRjcVhqNXRhVHRVQU9qZXVQUCtHWHpHaFV6aTFjc2pxRkNPMmhh?= =?utf-8?B?NGFYUXdpdm5TOHBzelZYL0tTWEVrYnFza0txd3dJZ3kzdHhxL0RFRndiQjNE?= =?utf-8?B?MjlhQUFzMnZOZnVqWGxoWmM3NnRVOEljZG85MDNPeXlEay8wVzVmcUVkeG1n?= =?utf-8?B?dWs0ZXBSc1hBQUZJMUo3UTRRRW5hSUxQSy8xckJHS1E1enBqKzd6akZYQnM5?= =?utf-8?B?alBVSDcxWkV3eW1PeHYwa1JGTGlDNmlaUVpKall0Rytlbk1TMXluK3d0d1dp?= =?utf-8?B?TDJYbDRjTE02UWgrN3EwTzVnYUNSeHhESFJJaWNxQkRiS215aVRpa05yLyta?= =?utf-8?B?ZURhS2tLanBwalpJTE5rd012Sm5WdTdFOG9JSTBjcUJ3SHYrK2x2L05FTDBp?= =?utf-8?B?MVdnWlFEOTZsT3NzN1ZaR1FaYUpOditoNGQ4L2w1N3RKd0dtMHFGU2JqNjIr?= =?utf-8?B?N2puUHlEUEdadllyQWhpdE5ZakNYd2JDU2ZyNlZZZGd0VkkvSkZBbGRUdkdr?= =?utf-8?B?eXFGNnkwTXpTanF5a2xsM1NXVmhvcjZXaURBT0NRSFhHV053Nkd3WWxtQXdl?= =?utf-8?B?NW04YVNyQjlPNDhObWQ0aytSd0ptSlovZ0RPZUJRUnZIWm5sdlNVaXB4d0Ri?= =?utf-8?B?RjNDRk90QTBHS0ZKUnNSRld1SWozSmNXMVJEMDdPenhTaW9PMkd6TkRHVkZo?= =?utf-8?B?aCtXOFpzMGk2ckFGWnM0VnVMWHpESmFadk5kQTVFRWtybEloeTFCVXkwVnJv?= =?utf-8?B?TitIVjI1RFBKdzQ0c1NwQUZDOE9CVE5GbC9WSHY4TG9FV3NYcjk0eHlTRDlr?= =?utf-8?Q?Xt62DxcmpQ/6HOVDMWSsm5IpJ?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ba06e4c-d137-45d8-a47b-08dce8426141 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR12MB8830.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Oct 2024 09:11:38.0266 (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: LQxpL+KLfMu1ZEAReNvye1lE3GKA8nzACFEYoulsLp5vbiPkiNdD2MfJIP1XJvOC X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB7621 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/9/2024 8:48 AM, Kusztal, ArkadiuszX wrote: > > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Wednesday, October 9, 2024 3:03 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/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 would go with versioning. I can preserve old function names as it's basically the same functionality. > ack