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 7B4BC43FDC; Thu, 9 May 2024 11:30:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 03910402D7; Thu, 9 May 2024 11:30:14 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) by mails.dpdk.org (Postfix) with ESMTP id A2BD1402B7 for <dev@dpdk.org>; Thu, 9 May 2024 11:30:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715247013; x=1746783013; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=AIBSBQMO86abTZkUiOdHz/V9HwQWdO+0EK0VXBBCins=; b=GRREh73Ta+Mn8giunI1So4T3e/w19IasP5gRh5YQROBsmiFfEN+Jl7LN 4dGd3tQ4PI2gxmo2CRsJ8Jn4GZFHFZDnIMjQX244G/did4oJwoam/C/C0 od0edibz9NisDPkDzr0DOPUS47Xfk1XldYbRzyesVFYoCtXRtsLmcB7YA zQbd0ZT28+36m8Sx9GzYv4Y7RG5vGOQiIVagVNFREBoHCHkr02Wm0Timw F8/MmEylA8YSDMr9m7CrgBs8/75xlstXCOE6uvOkxQt1MVsTsPjE+y2VP G8vHsxz7z98ArgA3VKeUjImhpWcVwLwVdcKLGvDLsbVB3pDtlHsJk17Gb A==; X-CSE-ConnectionGUID: Ywws3LxzRZO6SMOjzOxxqg== X-CSE-MsgGUID: JFgGV/r5QrWM3iwPPJWKMA== X-IronPort-AV: E=McAfee;i="6600,9927,11067"; a="14976669" X-IronPort-AV: E=Sophos;i="6.08,147,1712646000"; d="scan'208";a="14976669" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2024 02:30:11 -0700 X-CSE-ConnectionGUID: P3P4VfgaT2WFdHmHEvdkyQ== X-CSE-MsgGUID: /pAJ0CWGSxGtC0jGAihqaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,147,1712646000"; d="scan'208";a="33866804" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orviesa003.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 09 May 2024 02:30:11 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 9 May 2024 02:30:10 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 9 May 2024 02:30:10 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Thu, 9 May 2024 02:30:10 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.100) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 9 May 2024 02:30:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jzIUV3eTevBqoag3+DFfGPY+vuq2Crjz2JNKAJ7xzbZx2zr9A8BEYJACmuuzWHP/m3BiN/l27i9kNB0ERyT2+RHb33LrDPmIrX0lRasOBHhCNBEXkIHJ+P3cCBffBT+iIzWrH7Aq22Kfa21xeujMvSHLmYK8SXoQ5UR8C4Pdgw0dGceO6ONrHt6YAQSWMDZIGQu3BzzBhrWBAwV55+drcO0bXhwjGZzersVOlkNnROgM8ygiR0N8c0weZwxH9rf6qa4wWnGoT6z6qCJlKDu6iSY5Ng+2R2uMz40No4HfF1GuFKE0vthyOIefHNcessudk2mmTuc99Zh2BcAiMMKjfw== 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=0NLOoGVXQAQh9z9HcYNr590OJtHIfbvYo707p2cVgqA=; b=QCQZjOxPpbyZRx6QiXT94hj1kzRnmM+9ybTRKrvovvRrVRQ7kY/jpFy6NN8QNypV3STaIfkfeLakJ9h7OhqPyhYoAOemCtEgsBV4xU+SWwt6sJvD2UUUfL7zUV6u/iyfBoxoA4N6bp1FcR04j3AgQec726aSl4sNd59xEzis7PPQWnJdhTTokV1sSTumQezooxQNu7jA108rpbXVpxZNY3yhQGkdii78Ao+LfnrYnsP2CxB1KIKIBFQEPP/TviLnUSFh9/jn0bqkaz0rY2LpJtb129pZPe52TurH/slH5KqWAk0y0KeEuVbe8d6ND7Pi6NplHlQpss2IbDsvc1kscQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by BL1PR11MB6027.namprd11.prod.outlook.com (2603:10b6:208:392::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.46; Thu, 9 May 2024 09:30:02 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::487e:e20c:ad88:9c0f]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::487e:e20c:ad88:9c0f%7]) with mapi id 15.20.7544.047; Thu, 9 May 2024 09:30:01 +0000 Date: Thu, 9 May 2024 10:29:56 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Morten =?iso-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> CC: Stephen Hemminger <stephen@networkplumber.org>, Ferruh Yigit <ferruh.yigit@amd.com>, Mattias =?iso-8859-1?Q?R=F6nnblom?= <hofors@lysator.liu.se>, "John W. Linville" <linville@tuxdriver.com>, "Thomas Monjalon" <thomas@monjalon.net>, <dev@dpdk.org>, Mattias =?iso-8859-1?Q?R=F6nnblom?= <mattias.ronnblom@ericsson.com> Subject: Re: [RFC v3] net/af_packet: make stats reset reliable Message-ID: <ZjyXlOE3bGj7Mbwq@bricha3-mobl1.ger.corp.intel.com> References: <20240425174617.2126159-1-ferruh.yigit@amd.com> <20240503154547.392069-1-ferruh.yigit@amd.com> <20240503150011.55681b97@hermes.local> <432fb280-96e3-4079-b987-990d509b8c79@lysator.liu.se> <20240508082339.6bf74202@hermes.local> <834102e5-8f4b-4b67-9f62-8e8f61403b39@amd.com> <20240508135418.55505105@hermes.local> <98CBD80474FA8B44BF855DF32C47DC35E9F431@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F431@smartserver.smartshare.dk> X-ClientProxiedBy: DU6P191CA0046.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:53f::20) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|BL1PR11MB6027:EE_ X-MS-Office365-Filtering-Correlation-Id: 8c2d6dc4-cd4b-434d-73bd-08dc700a9a12 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|366007|1800799015|376005; X-Microsoft-Antispam-Message-Info: =?iso-8859-1?Q?Mip6/nU/2cc7qLrd1Dl2PVFDDtsGDZ5ZCmRmZrusNjNGwKSJdQXJbBtoS3?= =?iso-8859-1?Q?JA1bg0Ato1duFzbIapbMGaqmPzWBgN5yQ1e6nKR3KoOei+mXMxftd3cB0n?= =?iso-8859-1?Q?jgg7IuGHCT59CAWdiaoah4HkuRQneCZuFOwm3RJs+n94fmMNmsKS/5HE+8?= =?iso-8859-1?Q?1a0kVrczFom2Km424ccgeLYapP+64hYdpCEnaYtWt4dskBJ9blX7spsocb?= =?iso-8859-1?Q?I6O/cFL3csXNbXMNSsPsW7XEgEkuDRIoOjACbAsWXaz2hR8YqWGqVkA2m5?= =?iso-8859-1?Q?nuYYwHAOCwmqDNntKhWv+ropILE1NY/LbcJHx58DOjIrAuSwxCEfJb5zO2?= =?iso-8859-1?Q?bkeYF2qtJY3AWDLAzdrL02U6Xh6N1HWwApSsd2gbNFHPv6rdjoevvxl/VL?= =?iso-8859-1?Q?KXp/Tpq3cSd5HXsTKKsK2Cca7NMgb8GXz/QEerDjr0WalWdxAKS/IlrWwf?= =?iso-8859-1?Q?FcKsYrjQ7vA+Dedavvd+x5lbepkJsXBxCdxL6bPAQpgqkowptN7jVr8I0b?= =?iso-8859-1?Q?OUecSkOLduaeHlbu0cJdCWzV1ga2wLWlryUfNEexkkK6qUqZH+497LFZ9L?= =?iso-8859-1?Q?1xSmY0w/cG2oeTjqZhKre6ByNTTzMKFe3wWzoTLqnomXlbhjxVr4f22LV7?= =?iso-8859-1?Q?meEKDC4517CRv65ZGLbxQbrxGAfQaF6nT4bET0ukBhL312ofNZWGrUtTJd?= =?iso-8859-1?Q?TkIk4h5RKcKJ3f5fFm6VGCAFaqzeZchOTfqWHFl36cP4qfxaWAZDtqW16Y?= =?iso-8859-1?Q?WwW3tui9fzEEbRUmhh9/TK+IzUOc0CtCGI3MC4ws8Dpd6amFVtWQhn3n4j?= =?iso-8859-1?Q?s3ckOp3dyDBI66XJYE6B/G3q3CA18VNJH+4ZTyZNfnpXM3QQdcqajVylsI?= =?iso-8859-1?Q?9cNm24PbCjYeuSyK7+5Z08P0lGfe5pAtrDqE2dCPqNOC32dKCejvre/Vl1?= =?iso-8859-1?Q?d7Uwt4w2f8/guL2pXQxb3NVrD4jaHsjgdzwBrva3gDyNFkHZC1q2OQFxZA?= =?iso-8859-1?Q?kUhr1lfsQyhWpVuRa6F4bLwY2iY3IuL0TIMz3P74oEo+8kRAun7ssOu0QC?= =?iso-8859-1?Q?D7bdSl8YpphlrxOpEmlGUJbMBzvuDJ/OreNcu07Kg+2rmQmTDZMJq/A6P/?= =?iso-8859-1?Q?Qn2Utj4uFm+WP+EgYQNVH1KX8ssV++5kXqZjJVcyhj0MPRrS2FKE6Ho7Sh?= =?iso-8859-1?Q?p7fgTj5VWhQPCpCPuuRoVsJEIeYy30po24xA3w9kxZFgGyvj3GlmaSZydS?= =?iso-8859-1?Q?PFkHsBe+U2swHpPYbGYQ=3D=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(1800799015)(376005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?XIhGZYPsEwf1m8ft5AZRvy+geD4xczWEacIIo1cZ3NRI2QuQ1Z9IsvxbTj?= =?iso-8859-1?Q?GBMSzlqOFPheaWwPVCCBy1I1JloKo5C7k14E1TDDkUyn5BRZ2qKtP5Pg3P?= =?iso-8859-1?Q?i52GcK8AAByarhEdKRrj32yKRUtkd7tpplY5DnXeZZzOMjPIcjnhoFZR5s?= =?iso-8859-1?Q?fYIGajVtlAs45yputcxf+pS6J+OQD84k7Ti6OwLUECmtR1pM09I7Wf9kWB?= =?iso-8859-1?Q?hUB6bvZ84+9uQY3WEisvovLaUIlYN4rk19F4goqkt9p9DLS9e/FcpXm4eq?= =?iso-8859-1?Q?gW01eFLAJ7BLttChCoCTjb9H7M2kmOWCjuO/QJk3Tzg8Gbc2GAfmHo2zVI?= =?iso-8859-1?Q?GlrRnPos38lO3DqHFIn2Yk1AvmO1WvG1mEUCWaGkQrJzCqDGxZApKokVDn?= =?iso-8859-1?Q?/yumYUNuk5ijB9z+PtkATsbbpyTNDLd0DRErj5E39MqsbNlazdI9mWxbfE?= =?iso-8859-1?Q?XICUEr6anHw3kSfrFm1kaoQOWKiV6junsvcOfeGk4JPFX50qG5NXDTcO60?= =?iso-8859-1?Q?yqrYIhxKZV2tACOM6dK786pdObb9aTQpERA2UjhxyVbM2h+adYHFO3ANx0?= =?iso-8859-1?Q?HFHtZrrOSlFZuHA4gy5Enel0TlIFQibYJcEgQGv3+3uyRLFNIvWxrjfzGA?= =?iso-8859-1?Q?FmACXAgmvQY8Jaa5UBF7hpuhbqCw3wuuIWelnG1xyQSXnYRj/NO/TcA6PZ?= =?iso-8859-1?Q?8wRTqmhSEYaSL7pd5f6gN3OGFptxyA8jeIc+HScFxdMWQvr98HRmsbMv+y?= =?iso-8859-1?Q?mEMK94lSu8VvbGFxtLfz5iYKW3CDqA6h/KXr6iNdZMpIKF+U4Ngj+s1tP7?= =?iso-8859-1?Q?veauSaIlx0IQFIhUVY4ZGpetfv0tASPuCF2Ud4eQRiY3dcdC2Sf1eA6XCU?= =?iso-8859-1?Q?bqWyichXE4QbxSZ4KmhgFkYkyIs7s98WS+xjSFqGmd3kSA1lFRTL0EDS50?= =?iso-8859-1?Q?aIvoaIEKc429qK1QBtLe1ZXYyNTgXzvJk8Z/bs0G2K7tcSsrLLlI1zIxiZ?= =?iso-8859-1?Q?59MJ6C4EjBtZOcJO5Vw7uEWOKgkGNXUWC6qFvi9aplI3g/nyvCyDGUCxux?= =?iso-8859-1?Q?2fj8gPLHBf94N0L3dOv/Ao9I443zzvE6IXikawX0fJL6bDgQgl3vrhsBpt?= =?iso-8859-1?Q?dR4gE+KiNVIXhUjm90ZacMquPep9a9eHjNoM4HG76Uc9JKy1wG+fpQBcYH?= =?iso-8859-1?Q?a+S5G/b+3wI6y+H3nne+dRdrp+FciRC54EmCHJuqllWEF+NJqYmqyaEM6v?= =?iso-8859-1?Q?CQZgjpCXeWr0EqYxbP1SabqNIokSHBvb6jyqF3bnM8pUw0ZA+cacRKCqPi?= =?iso-8859-1?Q?zoefsNO1bnEC4Ivy+MkSgR2GYwluX/4BXvOTN+5LoRQ+gf9xXFvM2bWk4f?= =?iso-8859-1?Q?txynGv+toL8dbl6ydTh4nT2PByBJEkSCVa2eshCvuUS75XhPK20tobZh8t?= =?iso-8859-1?Q?fURRXrdS58cddJFrvJMNAsW/sQmI0UnptBK514PDY5LFkFKN2/sFnOdn7t?= =?iso-8859-1?Q?j16FVK4Qn+52q/dxeFt/+usMwcuLi/8nfWYIeTAiwhc6LEAOT3+X+fykEn?= =?iso-8859-1?Q?dqtjDb+WnQYAu0ADPr82L2T7k72itCBjbRIIkjDUsxPc76EaabIHGDWXk6?= =?iso-8859-1?Q?5fDbdYYAnDjDEfk3VE5V/WKIExvYGbzCUc1EZECFuOjo+OxCGTen9NCQ?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 8c2d6dc4-cd4b-434d-73bd-08dc700a9a12 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2024 09:30:01.8888 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YEResAwChtbQ5PndpaPgH1PfKIKBc/BovpVPD320tyUmh4z/u+jU1Xx2I8ITYkMVerNfci9ByFBj6qCqMVWTgynLlXzYLe/AGXj1HAcknmo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB6027 X-OriginatorOrg: intel.com 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 Thu, May 09, 2024 at 09:43:16AM +0200, Morten Brørup wrote: > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Wednesday, 8 May 2024 22.54 > > > > On Wed, 8 May 2024 20:48:06 +0100 > > Ferruh Yigit <ferruh.yigit@amd.com> wrote: > > > > > > > > > > The idea of load tearing is crazy talk of integral types. It would > > break so many things. > > > > It is the kind of stupid compiler thing that would send Linus on a > > rant and get > > > > the GCC compiler writers in trouble. > > > > > > > > The DPDK has always favored performance over strict safety guard > > rails everywhere. > > > > Switching to making every statistic an atomic operation is not in > > the spirit of > > > > what is required. There is no strict guarantee necessary here. > > > > > > > > > > I kind of agree with Stephen. > > > > > > Thanks Mattias, Morten & Stephen, it was informative discussion. But > > for > > > *SW drivers* stats update and reset is not core functionality and I > > > think we can be OK to get hit on corner cases, instead of > > > over-engineering or making code more complex. > > > > > > I forgot the case of 64 bit values on 32 bit platforms! > > Mostly because haven't cared about 32 bit for years... > > > > The Linux kernel uses some wrappers to handle this. > > On 64 bit platforms they become noop. > > On 32 bit platform, they are protected by a seqlock and updates are > > wrapped by the sequence count. > > > > If we go this way, then doing similar Noop on 64 bit and atomic or > > seqlock > > on 32 bit should be done, but in common helper. > > > > Looking inside FreeBSD, it looks like that has changed over the years as > > well. > > > > if_inc_counter > > counter_u64_add > > atomic_add_64 > > But the counters are always per-cpu in this case. So although it does > > use > > locked operation, will always be uncontended. > > > > > > PS: Does DPDK still actually support 32 bit on x86? Can it be dropped > > this cycle? > > We cannot drop 32 bit architecture support altogether. > > But, unlike the Linux kernel, DPDK doesn't need to support ancient 32 bit architectures. > If the few 32 bit architectures supported by DPDK provide non-tearing 64 bit loads/stores, we don't need locks (in the fast path) for 64 bit counters. > > In addition to 32 bit x86, DPDK supports ARMv7-A (a 32 bit architecture) and 32 bit ARMv8. > I don't think DPDK support any other 32 bit architectures. > > > As Mattias mentioned, 32 bit x86 can use xmm registers to provide 64 bit non-tearing load/store. > Testing this a little in godbolt, I see gcc using xmm registers on 32-bit when updating 64-bit counters, but clang doesn't seem to do so, but instead does 2 stores when writing back the 64 value. (I tried with both volatile and non-volatile 64-bit values, just to see if volatile would encourage clang to do a single store). GCC: https://godbolt.org/z/9eqKfT3hz Clang: https://godbolt.org/z/PT5EqKn4c /Bruce