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 12FAC42805; Wed, 22 Mar 2023 18:38:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A3C6040E09; Wed, 22 Mar 2023 18:38:31 +0100 (CET) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2051.outbound.protection.outlook.com [40.107.6.51]) by mails.dpdk.org (Postfix) with ESMTP id 60BE840A84 for ; Wed, 22 Mar 2023 18:38:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ca9+vUSbseNCjsuXzyi1ZUrbeTggwPxLk7nmRYD2EMw=; b=ULu2K0F4u/ucIle6WLAcjtssMgigvvMbNG8nbXvuKBJCERtM/MOFoh4BeregFsd24v3KFDUEFpWXllYk6s66EuB/guqvXw+D/K5oLZe209zPo+YhlUQgJ3W6/uMTuCZ5xeH92TPa2iB0JM0LOPIqKs2sikoggmTO60Cyzy1ykuM= Received: from AS9PR06CA0629.eurprd06.prod.outlook.com (2603:10a6:20b:46e::30) by DB9PR08MB9587.eurprd08.prod.outlook.com (2603:10a6:10:461::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.37; Wed, 22 Mar 2023 17:38:28 +0000 Received: from AM7EUR03FT024.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:46e:cafe::d5) by AS9PR06CA0629.outlook.office365.com (2603:10a6:20b:46e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.37 via Frontend Transport; Wed, 22 Mar 2023 17:38:27 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT024.mail.protection.outlook.com (100.127.140.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6222.17 via Frontend Transport; Wed, 22 Mar 2023 17:38:27 +0000 Received: ("Tessian outbound 55ffa3012b8f:v135"); Wed, 22 Mar 2023 17:38:27 +0000 X-CR-MTA-TID: 64aa7808 Received: from d7484319b460.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E02A40FA-2BAA-426D-91ED-8A0996BFA522.1; Wed, 22 Mar 2023 17:38:17 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d7484319b460.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 22 Mar 2023 17:38:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Col2mY9D1B9J0x+r6ZX9xqsXIqUN9qsHtYQHUCKYQcK2ezT0b8ZkO1dhWo0SByzu3MXB1Sor/yMMBJ5jf4Bz3yJQ0cxWdcFede6CQc6mXJMi9aeQfhcgO+QGe5nLuhonoAd9IU2u2EA/qj+ESETO2vS9eV8K8u7jT5HaFFFPeuB3O05ZM6CAS4Kin+ZpPMgxddto/V/RyQAiNdpvaml2bkl+Szz9ib5amZ76YYTlYOvhtzMSg8VM/gkp+ou7b5QVO8CPpwWsAFmTznF8p/btNr3jgI2VSREMprq7WjQxTYbwrcDfJtQf28jcUdQ6oT1seIrAeL7WFU0pxzZYPxiolQ== 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=Ca9+vUSbseNCjsuXzyi1ZUrbeTggwPxLk7nmRYD2EMw=; b=JApgQSookxuO6UitHfMGePzRyLZe7VdaiN++uEK4z5UoM760FBipAXlmre/tXwo5s5Xhza/6EDgYRJUxy6bVIyXOOO6nBNHZZHpXiWFZ0OFoavGzDgDsWrZH1sytk4/xIO8Kb1QG6ZdnjGqQVqacWgjlDaiCxeChLIJ2CqXGL8QT8B0PoBc08kU2s3SG6a5AqiHDsk8pvTDfJtQ/EFwNnm9rguladQ//pt24isoEWMVDPs+lWoyuv6xqEaadKWgg2DogN9FD6ts2meKG5VyDKGdpo+q60RsbUyqeoDXlW6ABk+s3xXa3Umr+oz0DoKK4liVqwdYBwH/W98qe7X1dvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ca9+vUSbseNCjsuXzyi1ZUrbeTggwPxLk7nmRYD2EMw=; b=ULu2K0F4u/ucIle6WLAcjtssMgigvvMbNG8nbXvuKBJCERtM/MOFoh4BeregFsd24v3KFDUEFpWXllYk6s66EuB/guqvXw+D/K5oLZe209zPo+YhlUQgJ3W6/uMTuCZ5xeH92TPa2iB0JM0LOPIqKs2sikoggmTO60Cyzy1ykuM= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by AS2PR08MB9073.eurprd08.prod.outlook.com (2603:10a6:20b:5fd::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.37; Wed, 22 Mar 2023 17:38:13 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::910e:e35f:b1eb:ae9]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::910e:e35f:b1eb:ae9%5]) with mapi id 15.20.6178.037; Wed, 22 Mar 2023 17:38:13 +0000 From: Honnappa Nagarahalli To: =?iso-8859-1?Q?Morten_Br=F8rup?= , Tyler Retzlaff CC: Stephen Hemminger , "dev@dpdk.org" , Ruifeng Wang , "thomas@monjalon.net" , nd , nd Subject: RE: [PATCH 0/7] replace rte atomics with GCC builtin atomics Thread-Topic: [PATCH 0/7] replace rte atomics with GCC builtin atomics Thread-Index: Adlc0x2jp4hZ/JHqTt+4XE4Z0dKiCQAAqo6gAAGcVLAAAOhc4AAAnqUA Date: Wed, 22 Mar 2023 17:38:12 +0000 Message-ID: References: <1679084388-19267-1-git-send-email-roretzla@linux.microsoft.com> <20230317144226.2f26bad1@hermes.local> <20230317214910.GA31884@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D877E1@smartserver.smartshare.dk> <20230322142134.GA29057@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D877E6@smartserver.smartshare.dk> <20230322152932.GB29057@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D877E8@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D877E9@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D877E9@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: F5423B86448AE1489FBD2D6E96C126CD.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5814:EE_|AS2PR08MB9073:EE_|AM7EUR03FT024:EE_|DB9PR08MB9587:EE_ X-MS-Office365-Filtering-Correlation-Id: dcad65b0-62d3-40e0-5781-08db2afc3ead x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ve3F5r4ZssbhagSU8yzGB/N41ZF1CyG3jZJRwv2mijo4xfS0j9dGXlhZo6/bXn+I1gTyOKIxpPCXKj20E1h9Xq+LG9aPSJBEFqxh2pqMmiRTtsNoeeiDbEljIMMNZpU9Z17s6C4svhD0blECoNbKDWDSI44PpCU3Oer3C7tdKPYpqSy0GzSPCzHS1WUg+YVCXZDhuvPF5UKTAut48wFPi0TMshbEuilzQlLxps3vLRzxB64d6Ydgo5UHWc/8B6NUlPnFNEelinmjHRjeut+iWzhs2FlIDjFLHoR//IZifef1LCl2rxlkt6Gblb1twzsvPio/Pq1IZCmOQNjpA2A001I8GgtP4k4pZaCVgRivq0G4v4m3SxjI4Q0bgL0Ab938ahk4M0lmJYJqyJhY5wXGWQhVVs2N36XMn2vTIui4L7gq84K6LqlvJ58hBsYM9EM76YXV2B3d/ZLQpXMjNRr35JWv4+DY1YpS87d8eEbP5C1gk8XiuifPPxPldwasPStBc/E/grZ46M5xA0yGP0L/yOzp6cxTVXzOVaybVPlf2n4GQiHO+82RBlYmgTfTXZ08L3B/LKGd4fsV8ijomx8Iq3pN7PmZcI3Yfo+lfhrUvhsMMHAliAJMlx1ZApC1wfEqefjLUoEmaE3EjfmkTs1JkDFuKnw3rajQzDi//wzXrNp/UQq5k2FDjl3xAG/ld+tAICAnH1JKaneuTpINdfjt+dPNZ8fiLUFkncJ2VofNGNY= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(451199018)(86362001)(33656002)(55016003)(83380400001)(71200400001)(66556008)(316002)(64756008)(76116006)(52536014)(4326008)(478600001)(8676002)(66446008)(66476007)(66946007)(54906003)(186003)(9686003)(110136005)(53546011)(6506007)(66574015)(38100700002)(7696005)(38070700005)(5660300002)(8936002)(30864003)(41300700001)(122000001)(2906002)(21314003); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9073 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT024.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1ecf560a-b635-4b0d-448a-08db2afc360d X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xIl7GIk6O8pPlW+KQRJ70274Oc4SoR5x0cOaNuU44HyckmL9kd/GIgXAqz+djvB6Cgufd+PtB0YuZMp543cdNsGdU8z9CtZmgB9OtrvFdgCPBrkzq9+2F0aGEEKddulIaLn4kdhuyOBfp1BVdEBNOY9nfHCuD1PqhHeG4BEuiRM5yAmNjbwmRKXTvJJz5pzqxaQ3v8jxOXPR9IjxXRvG/Bpm7mf8WFqQYOYTQRLKuPh2hQYDtEC/Mck41x6/sDVlhKmr5kiXaz96qSolQIWtgSwiS0fRdKC+EHqZLQ69qgdSnOxVthbHyl0sGX3BN5lsBjomGx7ebRe83b57jevnTxsmDGgW2FgjmsnTd7uSz/zLHbTyP8vfCLJAYPX80HQYe7ug9hBFW4xml9ahwkHyhG8z9YLmetiUlOW0PlbV0ChfV6KBdHC2ICJy59poaA6Dg3WGPfvo4ReZpME25f1iVu4+9/bHGiL99TVaQo75clqz8JSrWAzEWGoJFnsPglQqRHzjII59YMl9hv6l828pTA8laPSk3RXAz+JSfV/AsThuLbc68jciPYkzuZ6MNHXJEPLKyrqLKBohkoVqI9k1ZuDmRpXaeTJidXXecQBe1LGm+De29JEXnUv6uWAKgEQ+hAcE1RzvUaf82tSUbda1FEbwMEQ4mmxtVsz6SL7ESWxdHbqmewRObm2qje3uQ8Bdm0dRTY84Z9erNJUcJhva78a6B58ZxVqZiXf7LpPmjX2Jnb+dB3pggEkEfqiFxOS0q3vwERM2N4sghsJQgqarbw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230025)(4636009)(39860400002)(396003)(376002)(346002)(136003)(451199018)(46966006)(36840700001)(40470700004)(356005)(336012)(26005)(53546011)(186003)(9686003)(7696005)(6506007)(47076005)(66574015)(110136005)(2906002)(478600001)(83380400001)(82740400003)(86362001)(82310400005)(81166007)(316002)(54906003)(55016003)(30864003)(8676002)(33656002)(4326008)(70206006)(8936002)(52536014)(41300700001)(5660300002)(70586007)(40460700003)(36860700001)(40480700001)(21314003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2023 17:38:27.3948 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dcad65b0-62d3-40e0-5781-08db2afc3ead X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT024.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB9587 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 > -----Original Message----- > From: Morten Br=F8rup > Sent: Wednesday, March 22, 2023 12:08 PM > To: Honnappa Nagarahalli ; Tyler Retzlaff > > Cc: Stephen Hemminger ; dev@dpdk.org; > Ruifeng Wang ; thomas@monjalon.net; nd > ; nd > Subject: RE: [PATCH 0/7] replace rte atomics with GCC builtin atomics >=20 > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] > > Sent: Wednesday, 22 March 2023 17.40 > > > > > From: Morten Br=F8rup > > > Sent: Wednesday, March 22, 2023 11:14 AM > > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > Sent: Wednesday, 22 March 2023 16.30 > > > > > > > > On Wed, Mar 22, 2023 at 03:58:07PM +0100, Morten Br=F8rup wrote: > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > > Sent: Wednesday, 22 March 2023 15.22 > > > > > > > > > > > > On Wed, Mar 22, 2023 at 12:28:44PM +0100, Morten Br=F8rup wrote= : > > > > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > > > > Sent: Friday, 17 March 2023 22.49 > > > > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 02:42:26PM -0700, Stephen > > > > > > > > Hemminger > > > wrote: > > > > > > > > > On Fri, 17 Mar 2023 13:19:41 -0700 Tyler Retzlaff > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Replace the use of rte_atomic.h types and functions, > > > > > > > > > > instead use > > > > GCC > > > > > > > > > > supplied C++11 memory model builtins. > > > > > > > > > > > > > > > > > > > > This series covers the libraries and drivers that are > > > > > > > > > > built on > > > > > > Windows. > > > > > > > > > > > > > > > > > > > > The code has be converted to use the __atomic builtins > > but > > > > > > > > > > there > > > > are > > > > > > > > > > additional during conversion i notice that there may > > > > > > > > > > be some > > > > issues > > > > > > > > > > that need to be addressed. > > > > > > > > > > > > > > > > > > I don't think all these cmpset need to use SEQ_CST. > > > > > > > > > Especially for the places where it is used a loop, might > > be > > > > > > > > > more efficient with some of the other memory models. > > > > > > > > > > > > > > > > i agree. > > > > > > > > > > > > > > > > however, i'm not trying to improve the code with this > > change, > > > > > > > > just decouple it from rte_atomics.h so trying my best to > > avoid > > > > > > > > any unnecessary semantic change. > > > > > > > > > > > > > > > > certainly if the maintainers of this code wish to weaken > > > > > > > > the ordering where appropriate after the change is merged > > > > > > > > they > > can > > > > > > > > do so and > > > > handily > > > > > > > > this change has enabled them to do so easily allowing them > > to > > > > > > > > test > > > > just > > > > > > > > their change in isolation. > > > > > > > > > > > > > > I agree with the two-step approach, where this first step is > > > > > > > a simple > > > > > > search-and-replacement; but I insist that you add a FIXME or > > > > > > similar note where you have blindly used SEQ_CST, indicating > > that > > > > > > the memory order > > > > needs to > > > > > > be reviewed and potentially corrected. > > > > > > > > > > > > i think the maintainers need to take some responsibility, if > > they > > > > > > see optimizations they missed when previously writing the code > > > > > > they need to follow up with a patch themselves. i can't do > > > > > > everything for them and marking things i'm not sure about will > > > > > > only lead to me having to churn patch series to remove the > > unwanted > > > comments later. > > > > > > > > > > The previous atomic functions didn't have the "memory order" > > > > > parameter, so > > > > the maintainers didn't have to think about it - and thus they > > > > didn't miss any optimizations when accepting the code. > > > > > > > > > > I also agree 100 % that it is not your responsibility to > > > > > consider > > or > > > > determine which memory order is appropriate! > > > > > > > > > > But I think you should mark the locations where you are changing > > > > > from the > > > > old rte_atomic functions (where no memory order optimization was > > > > available) to the new functions - to highlight where the option of > > > > memory ordering has been introduced and knowingly ignored (by you). > > > > > > > > > > > > > first, i have to apologize i confused myself about which of the > > > > many patch series i have up right now that you were commenting on. > > > > > > No worries... you are rushing through quite an effort for this, so a > > little > > > confusion is perfectly understandable. Especially when I'm replying > > > to > > an ageing > > > email. :-) > > > > > > > > > > > let me ask for clarification in relation to this series. > > > > > > > > isn't that every single usage of the rte_atomic APIs? > > > > > > Probably, yes. > > > > > > > i mean are you > > > > literally asking for the entire patch series to look like the > > > > following patch snippet with the expectation that maintainers will > > > > come along and clean up/review after this series is merged? > > > > > > > > -rte_atomic_add32(&o, v); > > > > +//FIXME: opportunity for relaxing ordering constraint, please > > review > > > > +__atomic_fetch_add(&o, v, order); > > > > > > Exactly. And something similar for the rte_atomicXX_t variables > > changed to > > > intXX_t, such as the packet counters. > > > > > > Realistically, I don't expect the maintainers to clean them up > > > anytime > > soon. The > > > purpose is to make the FIXMEs stick until someone eventually cleans > > them up, so > > > they are not forgotten as time passes. > > Cleaning up the rte_atomic APIs is a different effort. There is > > already lot of effort that has gone into this and there is more effort > > happening (rte_ring being a painful one) > > > > Instead of having FIXME, why not just send a separate patch with > > SEQ_CST (still a search and replace)? We can leave the tougher ones > > like rte_ring as they are being worked on. >=20 > The FIXME makes it possible in the future to differentiate between the in= stances > that still need review and the instances that have been reviewed where > SEQ_CST was the correct choice. (Similarly for the choice of type for var= iables > previously rte_atomicNN_t.) Apologies, relooked at the heading of this patch, got confused with other p= atches. The changes Arm had done for rte_atomic_ to __atomic_xxx were not direct re= placements. The algorithms were studied, relaxed where required, race condi= tions fixed, performance benchmarked. IMO, we need to go through the same s= teps here. I looked at the series, we should just review the patch and make suggested = changes. Are we constrained by any deadlines for this work? I would suggest to drop 1/7. Arm is working on removing the non-C11 algorit= hm for rte_ring (not sure if we will be successful). I think it is better t= o explore this approach rather than the changes in patch 1/7. >=20 > > > > > > > > > > > > > this would just be a mechanical addition to this series so i can > > > > certainly accomodate that, i thought something more complicated > > > > was being asked for. if this is all, then sure no problem. > > > > > > Great. > > > > > > > > > > > > > keep in mind i have to touch each of these again when > > > > > > converting to standard so that's a better time to review > > > > > > ~everything in > > more > > > > > > detail because when converting to standard that's when > > > > > > suddenly you get a bunch of code generation that is "fallback" > > > > > > to seq_cst > > that isn't > > > happening now. > > > > > > > > > > I think you should to do it when replacing the rte_atomic > > functions > > > > > with the > > > > __atomic functions. It will make it easier to see where the memory > > > > order was knowingly ignored, and should be reviewed for > > optimization. > > > > > > > > > > > > > > > > > the series that converts to standard needs to be up for review > > as > > > > > > soon as possible to maximize available time for feedback > > > > > > before > > > > > > 23.11 so it would be better to get the simpler cut & paste > > > > > > normalizing the code out of the way to unblock that series > > submission. > > > > > > > > > > > > > > > > > > > > Also, in a couple of the drivers, you are using int64_t for > > > > > > > packet > > > > counters. > > > > > > These cannot be negative and should be uint64_t. And AFAIK, > > > > > > such counters > > > > can > > > > > > use RELAXED memory order. > > > > > > > > > > > > i know you don't mean to say i selected the types and rather > > that > > > > > > the types that were selected are not quite correct for their > > usage. > > > > > > > > > > Yes; the previous types were also signed, and you didn't change > > that. > > > > > > > > > > > again > > > > > > on the review that actually adopts std atomics is a better > > > > > > place to make any potential type changes since we are > > > > > > "breaking" the > > API > > > > > > for 23.11 anyway. further, the std atomics series technically > > > > > > changes all the types so it's probably better to make one type > > > > > > change then rather than one now and one later. > > > > > > > > > > > > i think it would be best to get these validated and merged > > > > > > asap > > so > > > > > > we can get to the std atomics review. when that series is up > > let's > > > > > > discuss further how i can mark areas of concern, with that > > series > > > > > > i expect there will have to be some changes in order to avoid > > minor > > > regressions. > > > > > > > > > > > > thanks! > > > > > > > > > > I thought it would be better to catch these details (i.e. memory > > > > > ordering > > > > and signedness) early on, but I now understand that you planned to > > do > > > > it in a later step. So I'll let you proceed as you have planned. > > > > > > > > > > Thanks for all your work on this, Tyler. It is much appreciated! > > > > > > > > again, sorry for the confusion the sooner i can get some of these > > > > merged the easier it will be for me to manage the final series. i > > hope > > > > david/thomas can merge the simple normalization patches as soon as > > > > 23.03 cycle is complete. > > > > > > Yes. An early merge would also provide more time for reviewing and > > optimizing > > > the memory order of the most important atomic operations. > >