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 5EB7D43F5D; Wed, 1 May 2024 18:19:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 460F4402C0; Wed, 1 May 2024 18:19:17 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2087.outbound.protection.outlook.com [40.107.94.87]) by mails.dpdk.org (Postfix) with ESMTP id AAB4D4027F for ; Wed, 1 May 2024 18:19:15 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dtAdbeRwXiadMXIOYF3SI+4kuDi7i8JH024Lf1c4TUBBnOFbAR4qsSRQDIhgAgbtPTAaBKe25zJBdEt59VhLip7mzK8Njg0IoQVqVWbzpENl0UgSCRCl2FAfhW1gzup9DB2iqsoTR77/U83UjoRsK3DyvfPOk4A7Z/40VnmOWcLWjaqFIt+xB/ZWlTCUFWYpoZO8PRyDDaG4ikvRM6V8oqHiNxTUD64A2yPPpw1GqCEydeGE9QcEqSYTpLRA7UzMKtjy5Vx2zMqnob+LK4zeV/rIeyVqDjfvN67j47nrtBVcAoJEJ/bk0s6JvXMDB/ojLVq2SctZYHIkhM6coNCgTA== 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=6ECbjQDz1OFILGn3y//hPQRaxIHGUwUWylDnO9fVpD8=; b=cY4v6dX7j6QJRp2zvm8LoPLWiyAqMvf5Xt8FJvQLbLQ1vj/KJRR09J5QEyjDU1Rn7P/HwNepAcOfGshw1IU7nvruZcK8s4j+nO00bLJbXPhAHwGpyfjdcSF17HR0zXeQSjx7iwqXAeRP6Zv6wG7VkehLRqP/j/z4f1H1xkXUgZohF1AZe26GnUlIkRTp6gtjp7wshohKEsrcfgLNMUG/TmOv2cu6eLrlqlgUp/sySGRo2ciqExhMELE6Yy64gOc6+G5ihyrGvCA4MazLV+vhC7EqkahSJ+3FRsXyJlDlUsj79AhepLEA3oR8Ku0KhVvfxpYtsglUxLapS8otu1XLcQ== 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=6ECbjQDz1OFILGn3y//hPQRaxIHGUwUWylDnO9fVpD8=; b=ED8EvhWKS7IETWafz6B1Z1VE/wOpSdaqeZKGsY5FtAQ+phBwzObN4tJMMjJVNPk50a4WuzprjzkpD2Ccgg9fobPJ0mqXZz3DBDIarV5kkxoDvzjJxozPnEkIhec909cTgzqRPSk+5VHqa7bcVVA0nuhvPrQbse5M98Q9AeIuYxo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by SJ0PR12MB7007.namprd12.prod.outlook.com (2603:10b6:a03:486::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.28; Wed, 1 May 2024 16:19:12 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3%7]) with mapi id 15.20.7519.035; Wed, 1 May 2024 16:19:11 +0000 Message-ID: <7e5dd3cd-ea50-4aea-a350-d88f46854172@amd.com> Date: Wed, 1 May 2024 17:19:07 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] net/af_packet: make stats reset reliable To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "John W. Linville" Cc: Thomas Monjalon , dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Stephen Hemminger , =?UTF-8?Q?Morten_Br=C3=B8rup?= References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240426143848.2280689-1-ferruh.yigit@amd.com> <108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se> 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: <108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0069.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2af::12) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|SJ0PR12MB7007:EE_ X-MS-Office365-Filtering-Correlation-Id: c79c0507-b4e6-4372-1a5a-08dc69fa6fa4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|376005|1800799015|366007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?YU1JMmllaGhxMFlET0p5ZWRuRWlmNWJMWmwxVDI3MGZPK3pqOTIvMitvaWZs?= =?utf-8?B?MjYrREZqUlp5b2QxYVc1cEl2MDFIZ3E5aEx0cTNRS084UXQxNHh6cm4xcVdQ?= =?utf-8?B?Tk9nQXl2ak5UbDdmZUVzbXBMeXVRYWNNVCtZV1UxMENGL2dWQ2tVT2VHcGVZ?= =?utf-8?B?V2RydTRVQkdUVEtuS3Z2WlRwdFpIanZJdngrdjZLMFBySlp5c3IzK0YrcGE5?= =?utf-8?B?aFQ5emdRbURUS0xXYWdvTFVWTFlOMTNHS0UvMjkxYVBZSjV5elcwLzUyTEVi?= =?utf-8?B?VHdJazUxVnYySzltaG9mOVg1THlYZVFVcmV0SzBIVXovRkEyN3VzRG5MMmtH?= =?utf-8?B?QlJpTFVjbThqQ2ZVOGFhblZZMkQ5aW1ncXgrYllxOE1obnp5blcrUVo1dVVC?= =?utf-8?B?ZEorQmZ3TlpVaWVENVBvY0oxUVd5UUJ1YnVoUUdja21SL2hHb0Z5aFNUN0tO?= =?utf-8?B?djVkeEQ0OEphcFVMemI1NHJMRGR0a1dZN2NNN2tzS0pzR01RN1krK1F3Q0Ns?= =?utf-8?B?M2tpTmM1TTd1NTVTWVdZWnNzS3dyQmFPT2EzeDh0NDltLzZQZnBwOFlkbUVR?= =?utf-8?B?dGQwQ1I4elh4Z1B4NHNPMU9ReDZtQU94WUY3VWRpcXpGeHhLN2FuTytqdFQ1?= =?utf-8?B?Vy9aTzUxN0hqaG84QmVzb3o5TzA3RUJSMWFGVlJ5ckFxZ0FRUXE3OVhnQVFF?= =?utf-8?B?RE55VmQ2N2pHTXpscWlCYUV3d2lJTEV3dkE1QkM0M2k3V3paeVNGOHZJN0dG?= =?utf-8?B?N29BNnBpWDhGTEF4cGRZR1IrWXJEMXd2S3Vrb2NMM2NhbTd4UkxrNVNwcjlK?= =?utf-8?B?MG9DVFNaMGpWYk8rTkdSeUVhbkZMOVplVmN0TjFzeENRZVBiQUV4bWNJS0Ja?= =?utf-8?B?S0JrTzR3bTZqVGptYk1EOGVFSzk2Rjg4RnJmYjdNOUZycnZVTFJtN1NWaXNw?= =?utf-8?B?RG9HdUVWMXIvampOTnNlRk5UMHducktic2NPNlJFaG0zQ2R1ZSt4TnJMWm5i?= =?utf-8?B?ZG50ejNXay8wcFRvdTZNbEUyS050cEQvSnAyWG81alNlL3hGYXRVbk9LKytJ?= =?utf-8?B?eWQ2OHZ1ZHQwcnZqWVBFMnlja2ZjbVQ2SGhua0lXYWVKRHh2RmswcHlOSnhW?= =?utf-8?B?dnM5N3N2QVh2dFpPNTFuODd2ZlNrckZqUzhXWjJFRUpLWjlTdHdhYW1jR2F4?= =?utf-8?B?WFZrTTBzY0dtTXU0ZEtVMVFBTExyM1ZQVzFseGNpR2llTWZYUmxzelpxUXVC?= =?utf-8?B?emhzd2V2VE1aY1FIaTdBVUlkQjE5THpnRXo5SnNIUGJQbmd4WXBlcVNQeE9O?= =?utf-8?B?cjlydFc3RVpISkhLU1k3QUhpaVYxa1Q3OEFQYUZxZ1U5QlltRThGNHFPdC9D?= =?utf-8?B?by9OeC9ndlhUQzZRTU9peU1BeHdVNkFSTHBKU1JvQVk5VzAvYURVaGx3L3N2?= =?utf-8?B?WUJ2b3JJc3Z6bDZWMWF1NU9JQ1JGenZPSGNTdWp2Wll4aXo5ZzlZK1NLMXMr?= =?utf-8?B?dkxqUkFweXdKcDI0aHJQVzQ5Q0E4Wkg4VzBVTW8rQmc3UEJPejQwQTRuQ05v?= =?utf-8?B?MHY4MFNOdWw1Z01WclM3MG1MaVY4MXFXejlVTHVXV1RyOGdxamdwMmNuS1Bi?= =?utf-8?Q?kXTHLdsPL71BAg8JmgOaZTeOAvKFzCtA2hKnGZgGREag=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(1800799015)(366007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TUdtVS9vTmF4eEZyaWljdHp2bmxnT0duMUJaVzY2eTdqS1VudldnZUVUTVhj?= =?utf-8?B?ZmNqWGZtSVZjeGhOVDVrYndsUUpUeVRnUGdURWFza2dJeWhIRkhjZHZsYlNN?= =?utf-8?B?TjJtM2liSWQ1WWN3MVBHVGRRaXQ0NGdJVHRVdWlYOGR2ZUJXTmxlQ1dVT0Qv?= =?utf-8?B?ZVdMU2tRM3VleWlPbnlSK3dONldHcFAyNi9hWU5wbWxGWVNNcUNmK2Z1OWh2?= =?utf-8?B?Yjl4bXlNbHpIWis0aTR6dm9qZVI5K2VYYlJGbFJMTTk2ekVpOUdTZi9hSkwy?= =?utf-8?B?RGZvbkdSSzl4SGVoOFBCTGFMallldnZOTDBHLzVSMWx2RjJVdkROVUdlbVo3?= =?utf-8?B?RU5uWEZzWVpDS3JoWUxxR0tuKzdvdlJUdFFzU09YTXVCUXhwQVlJdGRwMEhO?= =?utf-8?B?czJPMGwwT1VmcGk2NnIrak13cGljRk5GUjYvM1B1WUkrSUozOTR5d2l1MHNh?= =?utf-8?B?S1krZTdnMnY4M3d4Mm9mVHRMdTRVOEpmazlaazlMOHFubmhCUjcyZHo2dVVn?= =?utf-8?B?NkYxc3VGNlg3UzJlZzNZNlVJNmpMdi96RHZmblltalR1ZTNCWEk1R25rUkl2?= =?utf-8?B?ZVpBWU5idVkveUQ1WjNMYzgxUDIvZkRXaURwNm1xZTlzRURmcFF5M3ZsR1M4?= =?utf-8?B?YlZQMHExdVUxczA1Q2dEV2tONmdpY1l0TVBOZWJJYVpFRUJIOW1XRHZYd1pC?= =?utf-8?B?ZStOK3laeENqc2dsc1lEM3Y3aW0waEp0VFVLNDJnTVlCVjhvZzZOV2RPaUNa?= =?utf-8?B?RFpuU0t0S3VvTDQ5bVBiWUU4bGk4VHZhZHh4MFNwTGJmQUlxc3ZUdzA4bGNh?= =?utf-8?B?Vk1uOVErais5TTc1TTI4SVNvRVVrSHJsYThqQ29aSnVIcmZPbm9iVFQ5ekRy?= =?utf-8?B?RElzeFZ6Qkg4aXYxdXYwcW9VRnFGZ1UxWG9BSkZlcVFyN29xa1Y3Yzg3VWxW?= =?utf-8?B?eHJDQVJhNjBvUXVaNFJpbzdva1lrRktEa1dVNEZhYXgrVWI0TENESEdsY0R3?= =?utf-8?B?WWdGdmF1YVRUWHdQc3BMR1NHVERLeGVVa2w2R0hKNnFiWnQwMnlvZnFCOVJl?= =?utf-8?B?UkFVWHF5dWFzMmw3Yk10QU9VM3BwSkk1SFFpT3lyZno3RXFTK2o4M2JZNnh6?= =?utf-8?B?bytBVUtqbW1uSnFsREtmaE1ick55V0duelpIa1N0UmI3NWR2VDl1SHYxS0lN?= =?utf-8?B?ZERaZFZoeU5lSkpOZ3dXMG9PRm9MeUVtNVc2VEFBUmJpeW1STEFlMjZkcHpr?= =?utf-8?B?aGY4SWdOR2dYai9ZNVIxM0NBK3B3WEZvcGllbktQSDNtcUcxNEVScENFaWp5?= =?utf-8?B?WHFpUlUyWFZseFNROHI5VTJldnAwWTFVQVhEeVhSNzROL1liS2hia1BRenRQ?= =?utf-8?B?aUpDdjNpZmpNd0k3R2JoaDExTDJVNUVRcFdFSjJiMWMyZnhtYzE4NmZnWm5T?= =?utf-8?B?aVAzaHdxSEFXdGRrcVd6UnZTcE9BaVJ0bFNRNlpKZitOdGpFaE1qV1E0SGxO?= =?utf-8?B?UnA4M2lXcm5JWThNVGNyUWlvem15V3dsT1JzTEdKV1BWUWpueEd3Q1RLM2Zs?= =?utf-8?B?aVpmbkJ5cGE3UHZWUnRZZDNxRkhyU3B6cHc0NWxrRHZNeURCNVVwZEw4QlJ3?= =?utf-8?B?ZFN0NTZoMU5jdzJySnJWb3FHb3htaWZBakJLUlp0djlxVW94RUQxZnczeWxU?= =?utf-8?B?dUR0UEUzRGxwWVJUcnJoQ2R3ZUZoSEh4Wnl0ZGp2NURWRFVSc05MVHkzUXBz?= =?utf-8?B?ejdGSmFDampyTkRPMTh2NGpHNVFCbGJqN1BiYWdGdVhmYi92eE9hSWVjNzMw?= =?utf-8?B?a2pXMm15MUY3bTZYdERERUdHaEZFVDhYVXhBMkpjWFdSMTJtY0ZnQWJnRnBY?= =?utf-8?B?d2gwVVduSlAzZUFjdTFyaXdwNHFzM2FPMVNvTU1xNWV2dkR0Yy9iRmZ2eHRI?= =?utf-8?B?REk5OVM5ekFmZndLV0l0NU1vN3NTNnhxbjZjNlFYSHFNOTRkVTk5bkhwdzY2?= =?utf-8?B?WFMweTdYaEw0QXVITVNDS2p4UGl4Z0NhWTNPNUJQZ1ZXeWxsTC82UVdqSFF5?= =?utf-8?B?bnRiR0FRL2Q3RitMaEJVYkxPN0FuZFNDWG5GdWtHamV6MzdHcHFxOGlEbTEz?= =?utf-8?Q?Q0zUXBZJ4A7s7bYR9mgC1dDgK?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: c79c0507-b4e6-4372-1a5a-08dc69fa6fa4 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2024 16:19:11.8074 (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: 1FQUoz68fxdZRbZN1DP785C2b/nfo9OjBIKxtx6nYOQTlqsW2vFqQ8uJkIGfTb/x X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7007 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 4/28/2024 4:11 PM, Mattias Rönnblom wrote: > On 2024-04-26 16:38, Ferruh Yigit wrote: >> For stats reset, use an offset instead of zeroing out actual stats >> values, >> get_stats() displays diff between stats and offset. >> This way stats only updated in datapath and offset only updated in stats >> reset function. This makes stats reset function more reliable. >> >> As stats only written by single thread, we can remove 'volatile' >> qualifier >> which should improve the performance in datapath. >> > > volatile wouldn't help you if you had multiple writers, so that can't be > the reason for its removal. It would be more accurate to say it should > be replaced with atomic updates. If you don't use volatile and don't use > atomics, you have to consider if the compiler can reach the conclusion > that it does not need to store the counter value for future use *for > that thread*. Since otherwise, I don't think the store actually needs to > occur. Since DPDK statistics tend to work, it's pretty obvious that > current compilers tend not to reach this conclusion. > Thanks Mattias for clarifying why we need volatile or atomics even with single writer. > If this should be done 100% properly, the update operation should be a > non-atomic load, non-atomic add, and an atomic store. Similarly, for the > reset, the offset store should be atomic. > ack > Considered the state of the rest of the DPDK code base, I think a > non-atomic, non-volatile solution is also fine. > Yes, this seems working practically but I guess better to follow above suggestion. > (That said, I think we're better off just deprecating stats reset > altogether, and returning -ENOTSUP here meanwhile.) > As long as reset is reliable (here I mean it reset stats in every call) and doesn't impact datapath performance, I am for to continue with it. Returning non supported won't bring more benefit to users. >> Signed-off-by: Ferruh Yigit >> --- >> Cc: Mattias Rönnblom >> Cc: Stephen Hemminger >> Cc: Morten Brørup >> >> This update triggered by mail list discussion [1]. >> >> [1] >> https://inbox.dpdk.org/dev/3b2cf48e-2293-4226-b6cd-5f4dd3969f99@lysator.liu.se/ >> >> v2: >> * Remove wrapping check for stats >> --- >>   drivers/net/af_packet/rte_eth_af_packet.c | 66 ++++++++++++++--------- >>   1 file changed, 41 insertions(+), 25 deletions(-) >> >> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c >> b/drivers/net/af_packet/rte_eth_af_packet.c >> index 397a32db5886..10c8e1e50139 100644 >> --- a/drivers/net/af_packet/rte_eth_af_packet.c >> +++ b/drivers/net/af_packet/rte_eth_af_packet.c >> @@ -51,8 +51,10 @@ struct pkt_rx_queue { >>       uint16_t in_port; >>       uint8_t vlan_strip; >>   -    volatile unsigned long rx_pkts; >> -    volatile unsigned long rx_bytes; >> +    uint64_t rx_pkts; >> +    uint64_t rx_bytes; >> +    uint64_t rx_pkts_offset; >> +    uint64_t rx_bytes_offset; > > I suggest you introduce a separate struct for reset-able counters. It'll > make things cleaner, and you can sneak in atomics without too much > atomics-related bloat. > > struct counter > { >     uint64_t count; >     uint64_t offset; > }; > > /../ >     struct counter rx_pkts; >     struct counter rx_bytes; > /../ > > static uint64_t > counter_value(struct counter *counter) > { >     uint64_t count = __atomic_load_n(&counter->count, __ATOMIC_RELAXED); >     uint64_t offset = __atomic_load_n(&counter->offset, __ATOMIC_RELAXED); > >     return count + offset; > } > > static void > counter_reset(struct counter *counter) > { >     uint64_t count = __atomic_load_n(&counter->count, __ATOMIC_RELAXED); > >     __atomic_store_n(&counter->offset, count, __ATOMIC_RELAXED); > } > > static void > counter_add(struct counter *counter, uint64_t operand) > { >     __atomic_store_n(&counter->count, counter->count + operand, > __ATOMIC_RELAXED); > } > Ack for separate struct for reset-able counters. > You'd have to port this to calls, which prevents > non-atomic loads from RTE_ATOMIC()s. The non-atomic reads above must be > replaced with explicit relaxed non-atomic load. Otherwise, if you just > use "counter->count", that would be an atomic load with sequential > consistency memory order on C11 atomics-based builds, which would result > in a barrier, at least on weakly ordered machines (e.g., ARM). > I am not sure I understand above. As load and add will be non-atomic, why not access them directly, like: `uint64_t count = counter->count;` So my understanding is, remove `volatile`, load and add without atomics, and only use relaxed ordered atomics for store (to ensure value in register stored to memory). I will send a new version of RFC with above understanding. > I would still use a struct and some helper-functions even for the less > ambitious, non-atomic variant. > > The only drawback of using GCC built-ins type atomics here, versus an > atomic- and volatile-free approach, is that current compilers seems to > refuse merging atomic stores. It's beyond me why this is the case. If > you store to a variable twice in quick succession, it'll be two store > machine instructions, even in cases where the compiler *knows* the value > is identical. So volatile, even though you didn't ask for it. Weird. > > So if you have a loop, you may want to make an "counter_add()" in the > end from a temporary, to get the final 0.001% of performance. > ack I can't really say which one of the following is better (because of store in empty poll), but I will keep it as it is (b.): a. for (i < nb_pkt) { stats =+ 1; } b. for (i < nb_pkt) { tmp =+ 1; } stats += tmp; c. for (i < nb_pkt) { tmp =+ 1; } if (tmp) stats += tmp; > If the tech board thinks MT-safe reset-able software-manage statistics > is the future (as opposed to dropping reset support, for example), I > think this stuff should go into a separate header file, so other PMDs > can reuse it. Maybe out of scope for this patch. > I don't think we need MT-safe reset, the patch is already out to document current status. For HW stats reset is already reliable and for SW drives offset based approach can make is reliable. Unless you explicitly asked for it, I don't think this is in the agenda of the techboard. >>   }; >>     struct pkt_tx_queue { >> @@ -64,9 +66,12 @@ struct pkt_tx_queue { >>       unsigned int framecount; >>       unsigned int framenum; >>   -    volatile unsigned long tx_pkts; >> -    volatile unsigned long err_pkts; >> -    volatile unsigned long tx_bytes; >> +    uint64_t tx_pkts; >> +    uint64_t err_pkts; >> +    uint64_t tx_bytes; >> +    uint64_t tx_pkts_offset; >> +    uint64_t err_pkts_offset; >> +    uint64_t tx_bytes_offset; >>   }; >>     struct pmd_internals { >> @@ -385,8 +390,15 @@ eth_dev_info(struct rte_eth_dev *dev, struct >> rte_eth_dev_info *dev_info) >>       return 0; >>   } >>   + >> +static uint64_t >> +stats_get_diff(uint64_t stats, uint64_t offset) >> +{ >> +    return stats - offset; >> +} >> + >>   static int >> -eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *igb_stats) >> +eth_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats) >>   { >>       unsigned i, imax; >>       unsigned long rx_total = 0, tx_total = 0, tx_err_total = 0; >> @@ -396,27 +408,29 @@ eth_stats_get(struct rte_eth_dev *dev, struct >> rte_eth_stats *igb_stats) >>       imax = (internal->nb_queues < RTE_ETHDEV_QUEUE_STAT_CNTRS ? >>               internal->nb_queues : RTE_ETHDEV_QUEUE_STAT_CNTRS); >>       for (i = 0; i < imax; i++) { >> -        igb_stats->q_ipackets[i] = internal->rx_queue[i].rx_pkts; >> -        igb_stats->q_ibytes[i] = internal->rx_queue[i].rx_bytes; >> -        rx_total += igb_stats->q_ipackets[i]; >> -        rx_bytes_total += igb_stats->q_ibytes[i]; >> +        struct pkt_rx_queue *rxq = &internal->rx_queue[i]; >> +        stats->q_ipackets[i] = stats_get_diff(rxq->rx_pkts, >> rxq->rx_pkts_offset); >> +        stats->q_ibytes[i] = stats_get_diff(rxq->rx_bytes, >> rxq->rx_bytes_offset); >> +        rx_total += stats->q_ipackets[i]; >> +        rx_bytes_total += stats->q_ibytes[i]; >>       } >>         imax = (internal->nb_queues < RTE_ETHDEV_QUEUE_STAT_CNTRS ? >>               internal->nb_queues : RTE_ETHDEV_QUEUE_STAT_CNTRS); >>       for (i = 0; i < imax; i++) { >> -        igb_stats->q_opackets[i] = internal->tx_queue[i].tx_pkts; >> -        igb_stats->q_obytes[i] = internal->tx_queue[i].tx_bytes; >> -        tx_total += igb_stats->q_opackets[i]; >> -        tx_err_total += internal->tx_queue[i].err_pkts; >> -        tx_bytes_total += igb_stats->q_obytes[i]; >> +        struct pkt_tx_queue *txq = &internal->tx_queue[i]; >> +        stats->q_opackets[i] = stats_get_diff(txq->tx_pkts, >> txq->tx_pkts_offset); >> +        stats->q_obytes[i] = stats_get_diff(txq->tx_bytes, >> txq->tx_bytes_offset); >> +        tx_total += stats->q_opackets[i]; >> +        tx_err_total += stats_get_diff(txq->err_pkts, >> txq->err_pkts_offset); >> +        tx_bytes_total += stats->q_obytes[i]; >>       } >>   -    igb_stats->ipackets = rx_total; >> -    igb_stats->ibytes = rx_bytes_total; >> -    igb_stats->opackets = tx_total; >> -    igb_stats->oerrors = tx_err_total; >> -    igb_stats->obytes = tx_bytes_total; >> +    stats->ipackets = rx_total; >> +    stats->ibytes = rx_bytes_total; >> +    stats->opackets = tx_total; >> +    stats->oerrors = tx_err_total; >> +    stats->obytes = tx_bytes_total; >>       return 0; >>   } >>   @@ -427,14 +441,16 @@ eth_stats_reset(struct rte_eth_dev *dev) >>       struct pmd_internals *internal = dev->data->dev_private; >>         for (i = 0; i < internal->nb_queues; i++) { >> -        internal->rx_queue[i].rx_pkts = 0; >> -        internal->rx_queue[i].rx_bytes = 0; >> +        struct pkt_rx_queue *rxq = &internal->rx_queue[i]; >> +        rxq->rx_pkts_offset = rxq->rx_pkts; >> +        rxq->rx_bytes_offset = rxq->rx_bytes; >>       } >>         for (i = 0; i < internal->nb_queues; i++) { >> -        internal->tx_queue[i].tx_pkts = 0; >> -        internal->tx_queue[i].err_pkts = 0; >> -        internal->tx_queue[i].tx_bytes = 0; >> +        struct pkt_tx_queue *txq = &internal->tx_queue[i]; >> +        txq->tx_pkts_offset = txq->tx_pkts; >> +        txq->err_pkts_offset = txq->err_pkts; >> +        txq->tx_bytes_offset = txq->tx_bytes; >>       } >>         return 0;