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 ED91B43FAF;
Tue, 7 May 2024 15:49:25 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id D7F78433B9;
Tue, 7 May 2024 15:49:25 +0200 (CEST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com
(mail-dm6nam12on2072.outbound.protection.outlook.com [40.107.243.72])
by mails.dpdk.org (Postfix) with ESMTP id 9DBD5433B6
for <dev@dpdk.org>; Tue, 7 May 2024 15:49:24 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=DqI/8UoYvuA2l0/v3IfpG9r04skzaE321zbzLvyXMfua6OhZCVHZliOpbhHZ6LH0J39QUvEHEn6+8xl2VDVQ8i2hVVk0ZUy7qt7+lpptpDnkYXErzVK5l/B4DLagbvDM/4HjW4VTKYbztfoHNxFiK/pKdde2G5+frJLQUigUMrivaEldtFcgtGv/Z2bxD0TnOFZaZAZLYgRBxyEHlXbjf3jCEBnpNmHdW9VWVKO3zPAOsgzdO5BsO8DDJ516dKwhZeDfckmuozFXWWIwzmyUkTZ6t/nBCoV2S0DOTYOeRRKVAtNbFulIMJiTKJAzBeFKaXXfKBx8WrkWVAiA7cp/AA==
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=G6dwDkzQe+2buM9+BkdYlNMy08PER89bZZm3w5Nhruw=;
b=l/vVp14VBxWLOS9sZCKoQZAIfVF5cwn+HmOf0GYhIG4loT0esLyg5YmQGP+cT+y0yyVO+tXn/fIfEek0R5Xt1F8486yQbNQTflvTngMUqiNlAr4RwQMLvwTYP6I3/qkWqDvdf+C1upPS+PPV4r2DRxEKgBKBelNsw0eAUevqwSHxZ2iHUGd1svQHE2BAuAKUmcPRsIw3usJ7rKs4rsINh/mLWXYrd4OhwgusUpG4F6/DDxMCnUHT44HJ9TiLfSpTbe5iEJcjnDJ3HEyzm0lSQmZh0HqZcfdqLqzjRyPBjaVmoZ0t46inPP+oy1n1vk/sc8aIKlsZ8BqJARxCWWHEcg==
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=G6dwDkzQe+2buM9+BkdYlNMy08PER89bZZm3w5Nhruw=;
b=C9SLOkIPg3LKqJ/7PTjZbIjEFCn6x3bAOPtX8mwozdDQ8+Si2lQMCreb6uXsXiGHbhRGr8m+OkAP5Z4Fvc5k//apKGSOSCwvgYuqHZpT6cD9jiuuG1cm5ybf+JDvljiLLSNzTcp6sjCUTysn7/XmJCRlAuDY2RRKdp4xlHHKxco=
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 CY8PR12MB7609.namprd12.prod.outlook.com (2603:10b6:930:99::17)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.41; Tue, 7 May
2024 13:49:22 +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.7544.041; Tue, 7 May 2024
13:49:22 +0000
Message-ID: <c71d1994-0b1f-4923-a672-2b964e79d7f3@amd.com>
Date: Tue, 7 May 2024 14:49:19 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC v2] net/af_packet: make stats reset reliable
To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <hofors@lysator.liu.se>,
"John W. Linville" <linville@tuxdriver.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org,
=?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>,
Stephen Hemminger <stephen@networkplumber.org>,
=?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
References: <20240425174617.2126159-1-ferruh.yigit@amd.com>
<20240426143848.2280689-1-ferruh.yigit@amd.com>
<108e0c40-33e7-4eed-83de-eaedee454480@lysator.liu.se>
<238675d1-b0bb-41df-8338-a1052c1a88c1@lysator.liu.se>
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: <238675d1-b0bb-41df-8338-a1052c1a88c1@lysator.liu.se>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: DUZPR01CA0129.eurprd01.prod.exchangelabs.com
(2603:10a6:10:4bc::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_|CY8PR12MB7609:EE_
X-MS-Office365-Filtering-Correlation-Id: 1ebbae92-82fa-4139-28e3-08dc6e9c800b
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230031|366007|376005|1800799015;
X-Microsoft-Antispam-Message-Info: =?utf-8?B?VzArcUJ4c3V0L3NyeUo2RzFaWFI1RmN2RXhMdEh4eGIzQWt6VlpTajg1d2Jx?=
=?utf-8?B?T1I4bzFmUjQvTDM5WUswTVVFNkdFYXdUbHZrOU1CL0RYbDRETGtEeHlCRTQ5?=
=?utf-8?B?RzlCV2tVcmR2NllMMUEvdngrU2wvTlh3aEpkdy9ybTA5UEYrUG4yR0RaQVRs?=
=?utf-8?B?VEtJN0s5b21DckxPakNYQUZXRllvTHdva0tsR2hnZHpVazNlQmY3eFZtNmNI?=
=?utf-8?B?d2ovalVjTnV5YTh4akxpNXBrelhsa3o0SkI0ME0zbkVkTmFQZ3plQVIwMXRs?=
=?utf-8?B?SUs3VEZwZzNkNGVjdDdlNnJaTi9MOFdZTENzeGZLaXQwVmZLeXZiejFIZmQ0?=
=?utf-8?B?aUJMdnVKUER0ZmFCbis4emp6b0FmOFNOZTNPNHkzQWJ3QytyQmNSZ0M2aDNT?=
=?utf-8?B?ZWl0K2sxT050QkxybS9XSDRJd2hibTlwd2J0U0FtRlFzWnAzbXhXRDF2Wk01?=
=?utf-8?B?eFdCTWJkdUpoOUl5SnVPei9YOFVwdDUzb3RRUXBPYVFOQXNHT2R2RkMwYThi?=
=?utf-8?B?ZVpJL2RJekNtdHl6RVBrbEhMTDV5UVB6ZGxZMkdrWUhwTGNZbUtMalg3OStW?=
=?utf-8?B?b2JDalZLY1FMWGxSaDF1bENaNDBIRWNUeVJoRytLZEhCNnVTODA2YUdWVkQw?=
=?utf-8?B?NWVUN09qSmhLN1BXMDlsai9FbEl3MW9Eb0l5Z3N6SmN5djd2UkZicklxS2ZH?=
=?utf-8?B?azR1NmFVeHpRcVJZa2cwMi90SnhmcXpaN1h6alVwd0Q5aXZFV2ozc0VzWlRl?=
=?utf-8?B?TTN5Z29nODBlQmswaUdQMmRmZ3pPdUUzWVhJRnExdExJR3ZmVml2SkIxcXhJ?=
=?utf-8?B?Y2tYUEVQWUtHKy9XM3NDZFZPeGd6cjVNNW8xQVRwQ0tBbXZSY2JDM2VjdnBv?=
=?utf-8?B?TFozdmc1NzRYMmxVTEdLSkY0a1ZqbnZPQS9CaHg4RVk4NFpHREVmWkNJTklh?=
=?utf-8?B?TGt3U0VTR1YwcGRYZmY3Sk1zUWpoOWp0SzN5U1VOYW9MenY4RktVa0VtL0RV?=
=?utf-8?B?dnlwSVlPS1BRK3JocTVGTkhZV01xOXEvQUtWVkpqY04wQ01SZTNMZSt0U0hE?=
=?utf-8?B?TTR4L2VldWdhMlp0UDZha3lTbzZjN2pQdkcwN1E3OEpwWnZXUklmZUFEQW5F?=
=?utf-8?B?WVg4cVliVDZDb3k0WitwTlE2MlliVk83c2Jtc2lwdjd3UG1VZm9EM0JncDg4?=
=?utf-8?B?ODJ5MHJ2QkV6ZkJtT3YxWlVvaTNNcE1WdWtZWFpuYmFiU29QcmRvM0hOMzNn?=
=?utf-8?B?RWY2YVE0cjNUcjQ4RS9MT2F1TTFFcUZjWGovdzR4Si9hbGF5NFVXMWl1cExv?=
=?utf-8?B?alBMZFkrVGxtOFdCcFZSdkkxM2ZmUmo4bWVHRzRodCs5U0tMMHdJVHNKamY2?=
=?utf-8?B?OE4weGRrNXUveWlncWVnVERlUWx5WVNJSk1UTjdwM1MrZzNlbHZOVXNZbmQ3?=
=?utf-8?B?aFMvbDFSU05OTHZqQldzdFQzMHhnU3ZubXI2RTZyRGtBN0IrN1RBa1A5NlBR?=
=?utf-8?B?WEhUeEFZbmxFS2srd1pvM1RUWUYxQUJBcWRGTWsyM0IzYUtLWmZPN2JNSnQ5?=
=?utf-8?B?WUtQdXExbWwyUEZrZ2NGZlh0MXl4NGFralNYSmUvSWJseS9JV2F1U2NUT3dI?=
=?utf-8?B?SVFJNittMzBOUDZPUlRqODZHRGVqSUJEc2gvVWdVZk9EdnNwMVlYa01oSmdJ?=
=?utf-8?B?OWI4QzFtWEVvcVBMUXQveXluWEJ6S09MdXpYcmlLNE83NlRZNW5EbHZBPT0=?=
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)(366007)(376005)(1800799015); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RVNDTldGOGRzOEZrUjJuRmdub3BDUGRCVWhqM0hNTjdOWUh2UmcxTjhZd1hP?=
=?utf-8?B?bE84OHBJRTZubHZKYUJVcThhY09WUTlqOURjOTJOMkFpNmxxNk9GZE9hSS9U?=
=?utf-8?B?by9kZjlTeXJXcWxvV0tQS1JxZnpuZ21BdTE2Z3JkR0tPMHNaaDFCZjdSRE4z?=
=?utf-8?B?OTVtOW80Q1ViR2V1SWgxVnY5U3RZbzh4WjlXVUFvTzZYaHJPZWZYbFJ3ZzVS?=
=?utf-8?B?UHpzbDVtQXkraGMrUDlnUDJiYXhsblpUQmx3Y1RlV09jeGpGWHk3TER4Umtv?=
=?utf-8?B?MXlxZVZMUnJ0S3lPL2R5ZFZpZERma0ZxMnptNVJwQzZIaDM2T0tac0hFaXpp?=
=?utf-8?B?eThFOXRGdnJ3T1ZXVVNZV3lBbnI0V3FLTDNmcDNmWFVaSkNObDlhWXF2eDdC?=
=?utf-8?B?aW9BRkVXbEV3TTMrSkxFK2l5NXVmUzREcG9sR3BTSGFIdnc0SGlrK0pTM2Ir?=
=?utf-8?B?Z20xcHp2SWZNbEFwVHpQTERyYmpsTjhTR2k0N25Tcm44TTFVektIS2Z6Qld6?=
=?utf-8?B?cThSTDBGaXhxU0h0dTBXajFINkI0TVZiWGV6RXFTcmdnUXZ0YjdQbGk3WHgv?=
=?utf-8?B?T1M3OFF4Z0Yxa2ZmakNNZ1orWDNWcGp1bGlKbkFKME1KUUVwOUc0WldwWUtz?=
=?utf-8?B?MkR6UmlEb3F0TmtHeE5XMWFKWEczK1NvajREdk5Kd0xHbWRvYXU2WXhwVzBI?=
=?utf-8?B?d1JUMWF6Tm93NmFJT2hReXAxd29MMXQ5aHU3QlJ3YzNEWHVIa2dCYlBCMFdB?=
=?utf-8?B?OFpJaEtZL0FKVFBMNDhOeE9aM1QxdDltS3l6a1Z5VC9pc3FuV3RIREFrR3pT?=
=?utf-8?B?b294S1lXa3dQOTNPTS83bjJ2S21WeE1pbUpIN2hMYkdadDhoK2dvTnpHKzly?=
=?utf-8?B?MVpiQmJBSjRCaWMwRm5WVXc3bWk5d1ZaSmJIS1p4d1lwYTJVZlQyWXdpRFkz?=
=?utf-8?B?QXhxUmJjenFQNnkxOXk3cXB4Z2F6MWxzVzU2ZTRFTUR1KzhnUGxUTWliL3NS?=
=?utf-8?B?aU53YTVTTGVLMzlOUjh0am44eVRzQ0c0SHI2ZGpvOStaTFNxTytPNGkzQ0xX?=
=?utf-8?B?VGlxeXZrOFBNY2dQaHJ1VjBReXVjOThlREtCdENaU1VmKzJ0ZWVKeVNJK3Rx?=
=?utf-8?B?Z0hWNWwvWGRVa0RoMGZWYit4ZHRnVGJuSzh0VnBCVHlkUjFqL3gxMWwrMnNP?=
=?utf-8?B?Mm0yNUJuNnRLbkNXakI3QVpRdGw5dUsraGtWMnN1WWZnc2s1UkpvZDdCUVdl?=
=?utf-8?B?ZmhZNmVlOXE4M3FlTERNSCtmZlJGdVQ4am10bDgrMFZHNml4cGdaZ2s1TU9D?=
=?utf-8?B?dUQ3NGFBTlA4Y2lmUllFeHBZV2J3Z29iYU9xWGh6dXdjREJDWkQ1eTVzb0hC?=
=?utf-8?B?SnEwdGhhTjFzaWpBTWQxN2c0R1ZqVmpnaFg0WWtNVkpKWUN0Z3lrcCtTRjRH?=
=?utf-8?B?RGl5VzU0SzJxcm5yU2RWR200aStnT2pDNm1wN1QwNi93RkFWYXJqQU1jY0RP?=
=?utf-8?B?N0Q5ZUR3blNBREJZeW92N3VmOGY3ZFdHMnlIRCt5OWhmTlFya3hMWjVLVmNi?=
=?utf-8?B?U2FqdzA5dGFhYjA3N1FYR0pJc2lNb05yQ2grbzNGS3FrUjA2ZU40SitpeVM2?=
=?utf-8?B?aVY5clJHS294d2FLSzg3OHo5TjRKc3laN0hKdnl1bnNpTU9YYXFvUjE3aDF2?=
=?utf-8?B?aWp4ZTJtREQ5RkhkZ0c5NHZ6d0VsS1BJd29MSzNXUklJRzRORlpxMXQ5WWxD?=
=?utf-8?B?bVcyc0pFU0xGRWNCZUhDU2VlOWVJbmR1VzkwcW5TREJQN0EvQ2JZeC9ldmho?=
=?utf-8?B?akRnZXRxd0JKcUloSFgxY2d5VUpaNHFEbnJmdW5rZXlYbTIvU2dxOEordWZ5?=
=?utf-8?B?WFV3S2xvWHNTem53RjAzSWpQVGpVK1hNTVpEdjhWL0NERi9FSHBiVGFrSTJV?=
=?utf-8?B?YUp5eGtxOTdMdTZrdjc3Q2k5Q3VBZzNtT0VYM2lPdDk5RUtrYTBRb3FwRGtm?=
=?utf-8?B?bE5ZVGpNb3BNOFNvUnA2RGxDa2RDVXl3U1VwSkZvb3pxNVZ0V3VtcnZKWjZ3?=
=?utf-8?B?N2gzaHdmVThjTW54Yzdsbm9Pd3RBVTRFWE5sb2UxY1JZQUwvNlpJSCtDSmRr?=
=?utf-8?Q?yT8dNp6Op/2cwMPPIsqbEL5Y5?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ebbae92-82fa-4139-28e3-08dc6e9c800b
X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2024 13:49:22.4245 (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: 8jceMlEY9PdF+LOiam25sTc37ziYWj+fkrWASUusxW1W7Ws5OeqP2ss/5DEXEiPm
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB7609
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 5/7/2024 8:23 AM, Mattias Rönnblom wrote:
> On 2024-04-28 17:11, 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.
>>
>> 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.
>>
>> Considered the state of the rest of the DPDK code base, I think a
>> non-atomic, non-volatile solution is also fine.
>>
>> (That said, I think we're better off just deprecating stats reset
>> altogether, and returning -ENOTSUP here meanwhile.)
>>
>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
>>> ---
>>> Cc: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
>>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>>> Cc: Morten Brørup <mb@smartsharesystems.com>
>>>
>>> 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);
>>
>
> Since the count and the offset are written to independently, without any
> ordering restrictions, an update and a reset in quick succession may
> cause the offset store to be globally visible before the new count. In
> such a scenario, a reader could see an offset > count.
>
> Thus, unless I'm missing something, one should add a
>
> if (unlikely(offset > count))
> return 0;
>
> here. With the appropriate comment explaining why this might be.
>
> Another approach would be to think about what memory barriers may be
> required to make sure one sees the count update before the offset
> update, but, intuitively, that seems like both more complex and more
> costly (performance-wise).
>
We are going with lazy alternative and requesting to stop forwarding
before stats reset, this should prevent 'count' and 'offset' being
updated simultaneously.
>> 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);
>> }
>>
>> You'd have to port this to <rte_stdatomic.h> 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 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.
>>
>> 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.
>>
>>> };
>>> 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;