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 D685A43F69; Thu, 2 May 2024 16:22:43 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD069402D0; Thu, 2 May 2024 16:22:43 +0200 (CEST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2055.outbound.protection.outlook.com [40.107.237.55]) by mails.dpdk.org (Postfix) with ESMTP id 9706740299 for ; Thu, 2 May 2024 16:22:42 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UY1eJLyls16cePr1FkAbUfdclroIPUDumiO7MvM59GozNOlag94tsytiQxKIgbEvEXGnQvokjZx6UoCISDFZUxvXercex5iN/XZ9dLpi9irCtdNkzxugLXweu2gvtHt9rrwUdW6INPt6JeRb1A6iFsb6Ir6Q123EGcWVzhkhEkYIMcBWScljhOxcNMO9iOJFr9s0e0pThPNAjsrJr2JgdE9EiNzMx3Y2e8c2yhDT1JlhVRkux+BoGTsK3DQuu88+pqTs8xypjXKysZPVsMy81UoYjeoAvoW3I3mAynHmdnXNeOHCx8ovvXcBkOdCxJw9sQzTKbkUQvAWB/BfPiGo2w== 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=xr3f/2WsP7IKmcbO2o7rJisEkZPMlUuEZ6in8s9idHw=; b=M4W6aGBeKKQICigFXA2CqfgY1J9kZGC6UyjmqkZ3Nf0KWC84gHXtqyXuYX0lt1mHpXntm/UADUl0K2w/f68mQiAbr0vsnXaOQP3sfsiHrPs7vKhwoZcCNXbEa3gARr3m4DY7ebTQ/jfrp46qDti1GW/LTPlhiW4RyxOfq9U8nWmgWEyFS4DRTlrcEdRh5qUKt8qhGJvxf4uSOYhpW2+JSDuQy8boknZ0/TAx3LaXg8W1y1iC+nPFtBQzSFU/XxMzfhvN2RsN3s07K/MMc+l8gyjKdS0MXHn49huUkw+pW6uZCCbLeY3L+0TebipfkD5+ggk4vCyc962+UDRkn2D6WQ== 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=xr3f/2WsP7IKmcbO2o7rJisEkZPMlUuEZ6in8s9idHw=; b=l+hmaAL95q0I+tCea+I/pnDx+GbIEb/gJUFczTJb7YN7kVwISuEGu+rbF/Tb786BsNeKQ0JLI7WPb2gT4cCdaSnwk7IY6yAy91xe8zCzBiGDAhDk+TNrIvqt2n45BwEwWUBiGqC6TJQf+8lOfwrPv/HskLQaqFiHtaPKx8hmTTc= 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 SJ2PR12MB9008.namprd12.prod.outlook.com (2603:10b6:a03:543::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.30; Thu, 2 May 2024 14:22:40 +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.029; Thu, 2 May 2024 14:22:40 +0000 Message-ID: <422dd5a6-4ed6-4ae5-b613-b22a7cf6f77d@amd.com> Date: Thu, 2 May 2024 15:22:35 +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> <7e5dd3cd-ea50-4aea-a350-d88f46854172@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: LO4P265CA0198.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:318::11) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|SJ2PR12MB9008:EE_ X-MS-Office365-Filtering-Correlation-Id: b323d755-4a1c-4137-fbc2-08dc6ab352be X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|1800799015|366007|376005; X-Microsoft-Antispam-Message-Info: =?utf-8?B?bTA4bUFWOUxscjROVHBDc0JVSGNoV21iY205WHRvM2NxNUx5OWdOWmt1SVA4?= =?utf-8?B?NzZPTWJxTHlzV2gvQ014T2d4WkI2N1ZDWEdIbVBHNXdSQThxRVJwVndvOXo4?= =?utf-8?B?M0hkVnBrRUY2M0V2M1pVUkhjUVZiY0pENDI5aGd2U3pPeVlDS3BDNG1YcDl1?= =?utf-8?B?WUJ2Q0VlMStwSVh4UVYrK2tPSWRDUzd1RzF6K05ubmYwMHhlNEcxRWlIRlk5?= =?utf-8?B?MlpXZGxWU3h3REhGVXFmTXFuanpVOVUwZ0F5dHE4MGF4TDlKa1dOZk5CSTNZ?= =?utf-8?B?Ujc2MXJvR001VmM3ZTRzMDhSbG1vdTN4OGdMYlM4YmM3VTdJeU1DNk9GNFNK?= =?utf-8?B?NVpJUUkvTFVIWE8vRXM5elJSeDM2N0hDQVNpdHJPQnJkSWtTRDVuZWM1ZTF4?= =?utf-8?B?TVZYbk1MMHVNVmxwNllzYVRVU2Y0TWpPYnJqNWhOWTBpaFNETHVqQU1WMFB0?= =?utf-8?B?dXhHamd0VXozeUtZZGJTVjZsRnVyZGJVdzd2cWlZai9FNmhMMzFQMHVpUUdh?= =?utf-8?B?d0tvd0oreFJyQVJBeUVTRytOeVBiekZ3Q01sOXp2L1IxWXVoTUlPS3BtQTU4?= =?utf-8?B?VW94cVdWa1hmWmVGdnVHOGg3Vmg1OFRtTjNKT3JtOFQ1ZFFvdnF1TlpsVnhE?= =?utf-8?B?cG1jWEloY3l2NjZObHZmd0tqZG1TS05lZ01qcWpCbDdSK2N6WDQxZ1Q2bGxk?= =?utf-8?B?cDREMW90U3JhUGc5Y1JpSC9UN29mYjlibDRldStvYmRDTGNKdGtIWlV4RkRU?= =?utf-8?B?N3V3UUhqU2lHcjlLRzc0Y1FRK0xxbmtUTkh4Mk00Rzk4VkxJbHpiNmluVm8y?= =?utf-8?B?WFB5aUJKTWl3ckJWWnQ4NXJYVUpZRnR3UnhvRmVrbHdSbTJESWkzZE9XWXZI?= =?utf-8?B?YTduTXAzeGRWV0d6T1crNkhOKy9mTzNseWIwYUxpTU1wMHdlWkZaelM3cHEx?= =?utf-8?B?YjNZelk1OGtnZlRLNzd1bDRyQkVaYTFWWDM3Zis4Y2RFT2d0cTkyUUtWVzhx?= =?utf-8?B?TkljbUEzbWMxclNSSXVsNFZtM20rQ2Q4bE5SVUdJYzNNVUI2U2ZpWW9CQUpQ?= =?utf-8?B?VWc2bEtWU000MGdwa21yOWM0V2ZEZGVPdjl4aUpwb1ZxV0kyOHJ1bDQ3ZlZa?= =?utf-8?B?S1JRVXJGY0IwYlIvRGtxZnUzR3BFOS9kK2F6ZlQzUWxtSnNWWlhBYW1zZXdY?= =?utf-8?B?bzVKRVVaMUlRU090Q0JMUG0vUVhNTnVBNVZNNnJCNkw1dTFBb2NIbnVnSmZx?= =?utf-8?B?MUs2emdWQVBlNVlVOU1FNDBSOTNxVHV6akF4Z2Z6Q0k0MmR1NEJnUHlqcDl6?= =?utf-8?B?YUo1TSt3UHBlZTgrQStwcDB0Ym1vVzNhWERBTHVJVW8wa09oVWlZTlNDdVdI?= =?utf-8?B?MCtTbGRma3BVL1EycTZpMWFCU25ZUEd6Tlo3dUFTSERLNFE5L3FtdEpmNFdz?= =?utf-8?B?ZFBxTlVHbkFoaWV1bjJpY3JneE12T29MaDl4U2VEUTZoU2hYU0lEWld5SFQw?= =?utf-8?B?TFR0b0I0OGxTME1ZMVZudkdVMUlJQVl1NXFQZjkrMVNDcGpVQ01iV1hmUG9B?= =?utf-8?B?MEY0cytOTVpXYUZMMTRlL2o1cU5Ec2l2Y3h0MmY2b1E1aWk4d0pOa0hQT0c4?= =?utf-8?B?eVpRMTdxS01zd2REcDdSOXlRcUdVQlI3cFFaZDZuc1FBc0xFTmIwWEtkZWhE?= =?utf-8?B?cERtbWtZV3ZYZ3V0ZWhieW0vWmVZNkowMnZVenl4OFh5dFZ0NTBEbVpBPT0=?= 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)(1800799015)(366007)(376005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2JoM1FRVEkyWkc5aDBpYjBKbk1oVkd3M1ZEenNjQXNPbkZCTTEwT3k1ZWlB?= =?utf-8?B?TmpBODNsRUtVQkF2ejIvTDRiblQ3VW54ZWxCbGpCVXVvd2VMUlhSZE1mYW04?= =?utf-8?B?TGN1blRrNFloTUl5cXBGTDViV2FCSUhhOUtFdDZFTmlYR2NieUZrZjc0M05x?= =?utf-8?B?ZTdEM29ERVJlbENLMUVBVDZzUittb2czdTNHS2p5bUxBZ2JlK0R2cW5yM2E2?= =?utf-8?B?T01OSnRNcVdWYkdya3FPNVBrKzlocXNHU0hiaE1reE5EODdSRStITm94eEpj?= =?utf-8?B?amZkRDl4NDhOK0taRDJoZ2N0OU9QRnk0ZFFIQnJDb2VVWG5yOWNTVHJjanJ6?= =?utf-8?B?UmNxVnk4WXVFYnBya1RrdEFpWmRYemY0YlV6MVpTanZmZ0lEMlJYaHRFRkRP?= =?utf-8?B?bkRhYm4rTlV1cDhvczJQS2NibjlvaFBIMXhvRUk2NVljNlZSd0xaVVE3NDYz?= =?utf-8?B?ZktsNE5KS3BoUnZNbUF2a3h6citONjZvTERDRzBycjlsSXIzTjNyTVBYcnFT?= =?utf-8?B?WEJKeUdubWZiZ3hydlZacXBzWUxaNFBVb0F3enNKRlNpVkdLMUoySHRUZjRy?= =?utf-8?B?d0g5bUpsdUl1M09uVE5SMU9yc254bzlwaDBZZlZhZHQ4NXRxUnRJOWdoZ3ho?= =?utf-8?B?c0NmRjNTNlZ0QVZ0ZlMxcnRGMWk1UGpGNzZGTVVrYktSckVVZTM3bUxYSUg1?= =?utf-8?B?dGdNVnFrNG15ZXBRTzBoa3RKZFRMQU91ZEk1N0xSZW9XeWZoTkFGUVhRbWxI?= =?utf-8?B?Q1dLMkxCVGhIcGIyd2x5akNMYXFLMWZrZ2JsckE1OVYyV3ZiaGk0cmg5SEtK?= =?utf-8?B?Q2tKN2pjZkcvRXhWUVQ3UkhqTmh4SkcvWXFzdGdPMUErZFhkMml3RVBFd1hp?= =?utf-8?B?N0xIWXV6OGxNYXdiSTNxckcrZEdVMHZyNWxsdy93MEU5UEJXS29idkhtVnpw?= =?utf-8?B?YzM4cjhJdnBwOUUrNG92ei9qdXFIMTVYbE9uVDFtNStiQUhTZmFEUTNMbzFU?= =?utf-8?B?T283UnpSVHNFcEVWUjZtKzdpZzBpVUZJUmc2ME9wZkZtd3JPR1FLdm9Da25m?= =?utf-8?B?dW9NZVNEMkYzZ3U5anFJZGluM0s5WmYxUnhORHVOZi9FRkhFais1amZwNFVE?= =?utf-8?B?ckt1VWszSE1Tanltc01Db29IdVdtSGlyZ2szSVdyOHRhdXE5L2UzMkZzanpS?= =?utf-8?B?NTRld05RUmFTVGZnMlhPMlZCVG5pOHlEaXFpQVR5dWZEbXNjVHNIRVZ1blRn?= =?utf-8?B?dUVQT1lvemJZazBXUmdWblAwbHZlVDNwRVU2YWFlMHN4NnFNT2t4ajB3Q3ZR?= =?utf-8?B?MWxQOXFxMDcxZlF4Vk5jcWJhY2MrUWZXYVlmSEQ4bnFYM1FCc3RWd21QMkVS?= =?utf-8?B?ajlNdmpiSVh3S1lFeThVUXd5aFRCVC9KLzN0NW52SklMMzBGV2lqaU92UW94?= =?utf-8?B?MzdJVjE4eHExaEtXZjF3WlphbzZ6VW5LRVFKZEExV1JlZ2tqd2xyLzM0M01Q?= =?utf-8?B?NjRpTnMrbXRiekJtKzNJVkNYWDZFZU01TW0vblNsejQrMVZSbGhtL0ZBcG1l?= =?utf-8?B?T0JScXJOcm4zVFIvbGJOajBVUlg1VSsyMUkzNUtkeEpHUFk0eHVsT3Y2TjVF?= =?utf-8?B?eHBQaExUaXRKVzl5ZVZRVWYyYWhuS29oUWI2Y0dNdDlTcDE1OERlWm1HaS90?= =?utf-8?B?ek4vOXpWU2tIcTJ1NTRCNUtCd3hjd2JFMEVFYTlwVktQdUtNdUJIdDZQdTJP?= =?utf-8?B?aDBxSUhxNXdiNGt1Yjc1TWxJWVA4NGIyUzhxTW5ONUg3d0kwc0d5NDV5Z2Zp?= =?utf-8?B?VFN4TDZVNCtIb1d0ZmptOG0vTlZ5ZGoxT0RqRkNPMjFQNThMUHZpbmlxb3Ju?= =?utf-8?B?dlNTRnpMajlKc3RPUzN0VnVKemJzQmN2bWxLb3VFaGo4dUp5M0lCckh6ak9o?= =?utf-8?B?ZjRDMVBRVDdydCtWUVlVRkErY3Q1aTVlUjZIMUM3ZEZvdGY5Sm45YkI2YUFI?= =?utf-8?B?SXBHWllKTlc4a0plQjl4RkRNV0NVWHE0d3cwL0Fxd09odlRhVWtnMnVvNFRW?= =?utf-8?B?ZDlhWm96U21lakNGSlNMZFdSSWNjL0ljSG5oZVdwSDdXcVZPU1BCK3RHb1pH?= =?utf-8?Q?xIqhxAm14nxrXLPfO0x8QC8hw?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: b323d755-4a1c-4137-fbc2-08dc6ab352be X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2024 14:22:40.1666 (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: 7claUOia4RyTHRnyNkie4weO0Vtvf5SwomaXJZEYFEwYj2MAXvsxxF9BRdfbgwi5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB9008 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 5/2/2024 6:51 AM, Mattias Rönnblom wrote: > On 2024-05-01 18:19, Ferruh Yigit wrote: >> 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;` >> > > In case count is _Atomic (i.e., on enable_stdatomic=true builds), "count > = counter->count" will imply a memory barrier. On x86_64, I think it > will "only" be a compiler barrier (i.e., preventing optimization). On > weakly ordered machines, it will result in a barrier-instruction (or an > instruction-which-is-also-a-barrier, like in the example below). > > include > > int relaxed_load(_Atomic int *p) > { >     atomic_load_explicit(p, memory_order_relaxed); > } > > int direct_load(_Atomic int *p) > { >     return *p; > } > > GCC 13.2 ARM64 -> > > relaxed_load: >         ldr     w0, [x0] >         ret > direct_load: >         ldar    w0, [x0] >         ret > > Do we need to declare count as '_Atomic', I wasn't planning to make variable _Atomic. This way assignment won't introduce any memory barrier. >> 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). >> > > Yes, that would be the best option, would the DPDK atomics API allow its > implementation - but it doesn't. At least not if you care about what > happens in enable_stdatomic=true builds. > > The second-best option is to use a rte_memory_order_relaxed atomic load, > a regular non-atomic add, and a relaxed atomic store. > >> 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. > > Well, what you are working on is a MT-safe reset, in the sense it allows > for one (1) resetting thread properly synchronize with multiple > concurrent counter-updating threads. > > It's not going to be completely MT safe, since you can't have two > threads calling the reset function in parallel. > This is what I meant with "MT-safe reset", so multiple threads not allowed to call stats reset in parallel. And for multiple concurrent counter-updating threads case, suggestion is to stop forwarding. Above two are the update I added to 'rte_eth_stats_reset()' API, and I believe we can continue with this restriction for the API. > Any change to the API should make this clear. > >> 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. >> >>