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 2200F41BBD; Fri, 3 Feb 2023 14:56:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0D27A4067B; Fri, 3 Feb 2023 14:56:54 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 3926F4021E for ; Fri, 3 Feb 2023 14:56:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675432611; x=1706968611; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=QqwXZu87F4Qib+a3kkPAIRSfe7jhyoomxzBzxN/ELrM=; b=mKA5k3wnUoXG5Dmeup6Ia1m/IWSM0no9H6B1BWQlvPfNqBkONsGHllGc tcm3Y3tTi1mQVdXrtSxmnzMWGwgifwXSjnptH0xoPDSw0paFMsqTInTEo 7gnVIwwpvZrTz/28McOKXaNoLLFzbzvQ5cb/a+XAtdEMc+j5fbC6b0651 FjntDO/l62rbcyFtW4sTFBv2QMS8Yi19Jy2s7NbT9lE1mdaXdB8bANFpm dIta3rDCX1J9ulXBgg0q/u+DMLBjQRHdTAW4EHIY4mKdUvvh87ZEtNO8I o2jdIcaNAqW3O7bNkDyXkrjG+CqppObb9ew5ZofnAgU9D2KeWouM0acbD g==; X-IronPort-AV: E=McAfee;i="6500,9779,10610"; a="330882483" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="330882483" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2023 05:56:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10610"; a="839615185" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="839615185" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga005.jf.intel.com with ESMTP; 03 Feb 2023 05:56:49 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Fri, 3 Feb 2023 05:56:48 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Fri, 3 Feb 2023 05:56:48 -0800 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) 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.16; Fri, 3 Feb 2023 05:56:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LglQzLlBNG5MDhsv/3+8AII3hOiTrNOVQuKr4484F3svsPgccsHoRDdG5wcuXL74XIoEBOqBtUIqrZ2qttNYfRNlF4YzWIresqcmmYrCJSbq1CtJRHJw2fTbE5wLfvwu2QkkladFXtmt1Pe94VA71i/QwrA2TKA0l7kHJEtCs4KIPooMlUVk1EI9iVggXVNesNZxXjZ+5PeSAZlyPlFeB8dV4IWnXtoPAz45a1uktjSRSih/DXVHBetvKSapa3puMC+vJwZpY0biy5Eg7iGKuxRpKlWvcbrYhDOc6GLm4Vgu3QZcyaMgn5os5uTqHZLeM/PThVVxr8uMpVv0oTLLKw== 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=jFA5dp8Hvz5cFBJDWx49s/KqOxA1perdY3/YGA1Aj1M=; b=axH2v1t8LTJzm7vYzD0cVqK0bH0YIij/2Cl8SybLo2+4dHKR26RI13K+jZmv7TtwiIJDCfg1+2VvjW4FeDEY8IH/XggVBX6se92J2daaWWUB+PG6OQ6ivnqP/pabFujK7UVuMDr9Leku6keV8G6E73CnvXWOaV7Tzu6yG+PWXL5A5T88aLQwAxCvNZm6c4CwDu58vMeiNxf6pToEEnyYugKY+Wjcy8bQIRbLR54QHNe1EOkofty/+BKRJ3mN+o1kYU0S+hdMoDf15YYU4o9FYNzR5E7bIn0rK7TvNfunFJxiK9lL8ltz4qNtnivY/krXhKIbRo4R31Ks21ugPJQuBQ== 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 PH0PR11MB4871.namprd11.prod.outlook.com (2603:10b6:510:30::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.27; Fri, 3 Feb 2023 13:56:45 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::aaba:abb7:8794:def]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::aaba:abb7:8794:def%7]) with mapi id 15.20.6064.024; Fri, 3 Feb 2023 13:56:45 +0000 Date: Fri, 3 Feb 2023 13:56:37 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Tyler Retzlaff , Honnappa Nagarahalli , , , , , , , nd Subject: Re: [PATCH] eal: introduce atomics abstraction Message-ID: References: <1673558785-24992-1-git-send-email-roretzla@linux.microsoft.com> <1673558785-24992-2-git-send-email-roretzla@linux.microsoft.com> <1844463.CQOukoFCf9@thomas> <20230201214111.GA30564@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D876EE@smartserver.smartshare.dk> <20230202190023.GA32597@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D876F7@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D876F7@smartserver.smartshare.dk> X-ClientProxiedBy: LO4P123CA0023.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:151::10) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|PH0PR11MB4871:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d45b674-9efd-4052-2c25-08db05ee7c7b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lext42TiNbf1XTUQvPkEB95mJvQbPqpNm15BoDBD4541Oanu2lomKNBbEz/VaZ08fGbV/5BEOhAAPJB+QsrrRUiIzYctj6LmXY6IOgOOGsP/euKfEG0FZZ0zoB/xMYCE/sy1unXR/Vq2kMQtnQLGZFz7FOVyzqWlyo3cmnXYlMYIDcqlDdDFUsiDJvBz4O8FyOKZoOEOKt/BXL1UhNeyGQOsa8js/71++Y95ahIK02P2jmjUgWLYYV1+sz9TBUgSvGvqgCyEldmrpsBo6eGPx4w3151tQx3XbXLgpS/Sz/VynmYzmXcOFFcAn47ejnhhOuVgNEzFNiXClY8dsVtUHpbaf97TS49mjpUrAKZ/X61GCOxRAf7aKmNY7iOgO1vx4heOlQL/8cBwlDNK1yBli1YG807ZzvhdAmWe9l0hAQO0ui4IrwELFJBKYNQ0VdBuAXPlsdMczHii8dGxXBA/YVfnihqDSeuypXVfXLWHDtgkYBYSwNccElU4QPR8brdFd6cDXBqkblqCUNNpp53B2PfUUSqgcY9t4AMCvhz2Si/WUKzLvLyF7n+v+Ig0xk4u5wsbHGL+fE6wSXzLTYK7pFONLP2NDUjq+RK7xX2JKkXnMrbZyewZQQgV/SDNACQtUd0F+5/sQSL6+RtXydOyWS8xILXQvLG7lbHaSRnVzcR992aO5j9BCT9kOvZiHnuYnsgfKP/lKZ064VHuAujx1A== 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:(13230025)(376002)(136003)(396003)(366004)(346002)(39860400002)(451199018)(82960400001)(38100700002)(66899018)(86362001)(2906002)(4326008)(66556008)(54906003)(66476007)(66574015)(6666004)(83380400001)(66946007)(6916009)(41300700001)(5660300002)(6486002)(478600001)(44832011)(8936002)(7416002)(966005)(316002)(8676002)(186003)(6506007)(26005)(6512007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?jpowObLshlpyW5ghGJ+QxaqD5G3ilfIAn0fF215B5OhZB6hJrQR5uCG3tL?= =?iso-8859-1?Q?h7eijEsqDL/KGXyc0ekpkUJG9nyglV6QunqUiRZyzthECnpejG8JN6SUZk?= =?iso-8859-1?Q?FsaDlXGHHkE71C6GtY1Sp52p9UsMAfSGlvXMpArF+ch2L+Lt6LgyREquae?= =?iso-8859-1?Q?qCKcZtdZUwmc6rp+bDFG8qBKPTdNyRCCevNUT8dHlyTozmyx+j8gw2Dnve?= =?iso-8859-1?Q?787cQ0XnadTzRoMsvlBrlLfzUaQI0mKZVwIWhSVwF4lXaNqrZK2I1aRg5s?= =?iso-8859-1?Q?zP+SjdDUuo7WOtd8mjUQaH0srZytmP9QU5UlVTKXGoVRYJ+IMlaRGAr0f3?= =?iso-8859-1?Q?IbvpVWw/0MQJpRmuDkP9rVI98+4zBQ6kzuJHJhjelzHu65sPnxMG08pAeU?= =?iso-8859-1?Q?lEICS0P3M4ww12N/dWNIt+vSZOqoqp+x+KByUPxFV67qjdOlO24STA+uSC?= =?iso-8859-1?Q?XqRohqFlxHsumc4CEjK8FM3g75e2oh5EF6v/xdpxgBNTw+0XzWjgyb94zh?= =?iso-8859-1?Q?KOmpjYEvGXCR9mNWeJeVNDU+EZyJuVyrO9XxS3EcX6L7KG8YgULWWC+Qm7?= =?iso-8859-1?Q?qLp5GjyoOjFZEiHgfTnTsW3QAMpDd6gA6ij13zZnPZ59+CXajawAaghEJd?= =?iso-8859-1?Q?h8gFgY4+0ZqZOLZvWuc6EofnG2URDDm6Y3R4oi61BVpNUpxHHZMuJxczvR?= =?iso-8859-1?Q?hFR3Bs26fd+MH8aPnvVRwdG5gvLkoUJby//EcTVjO2BRt0s3SDvJxbAWX9?= =?iso-8859-1?Q?ORrNjAwvT00WdDqiI2jfc5OxbTCiDgTWgn3/5M7s8IwanrDSwLd1TNA7N9?= =?iso-8859-1?Q?Lp7lhZRk6mBB5tA2+/zwW4XDv/cOvunkLA5j+i1UuZWBPCwAPEMeJTJB76?= =?iso-8859-1?Q?y1FsvkkWkBRDTCROS/mEBrzuX7WV29k/fOeuNG9AKmaRpbx/7SgLUuWEzZ?= =?iso-8859-1?Q?XKERH16C5bzE8FeCcpGQ3k3fn9MMpVtnTL0bdX/0tFGWhajtB1u67sQAGU?= =?iso-8859-1?Q?bTcSOwkXwf2ydWWaYFKXk/bFKZuLs9mx16W728HcatjuMvqzHTpEP9qOyy?= =?iso-8859-1?Q?25duB4DC0IyqjNluPixtmY7vtYwlZXMqcIh3E7IZjzxe3lFgdlJk/SDnts?= =?iso-8859-1?Q?Ux13emVwU+c47YwUKep1sBTATY8eL4IjkQ2zYVrW17UU0+J/+hjguF8Jxv?= =?iso-8859-1?Q?KPjyuISnPJ0mXFQwWBoTXKPb5gZGjrLyToy8y8GGv3iOyRjAvTI4mNZyTh?= =?iso-8859-1?Q?2AnNvmMd3W69mYZ+IDqJrnLU7Vg08/7kw+QBRmUnJJfhrqFT79jL2NJI2F?= =?iso-8859-1?Q?rQcRJ9MPTjQoAgZ10jz9MPZTl5bvx5bZBIisH8hCgJ/aQft5HxRZ+Lpg6a?= =?iso-8859-1?Q?2+Gc6IsK7hc4rphdigL87SdCGK4f+U7eGY+/+wLJtLIne6WM5SMF4umfhS?= =?iso-8859-1?Q?gb7SX54/ZeLdsAqVp4yBeK30Ui6yyD22p39KVslWL6rptFDzMl62vRRoz3?= =?iso-8859-1?Q?+beC29fUnyLqcnTKa0yIsw3mBbio3lcDS1KK/6mrOC9TnVqXF94TbC4SGJ?= =?iso-8859-1?Q?xNDjbNsMaHknVMrQH6vJo3kCXTpNg/fQRk82c2WMY6o8qKMaKdWB1DHrQ3?= =?iso-8859-1?Q?kprRhiQDWDKx9rH1PSghW2ZnLX/7fWH9pbMjwgcyi8f/w60SjZ70Dg4Q?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 6d45b674-9efd-4052-2c25-08db05ee7c7b X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2023 13:56:45.4047 (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: bj2wUB+yYCFVZsLHHjLh89SaFgrBsUx25t1wTdPYdYdu7F2WYbzkKzfttIdWHkofsck61aOMecMsXc7xhYuMiFV6n72r6Uz0G/o/4dslnxs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4871 X-OriginatorOrg: intel.com 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 Thu, Feb 02, 2023 at 09:44:52PM +0100, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Thursday, 2 February 2023 20.00 > > > > On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote: > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > Sent: Wednesday, 1 February 2023 22.41 > > > > > > > > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli > > wrote: > > > > > > > > > > > From: Thomas Monjalon > > > > > > Sent: Tuesday, January 31, 2023 4:42 PM > > > > > > > > > > > > Honnappa, please could you give your view on the future of > > atomics > > > > in DPDK? > > > > > Thanks Thomas, apologies it has taken me a while to get to this > > > > discussion. > > > > > > > > > > IMO, we do not need DPDK's own abstractions. APIs from > > stdatomic.h > > > > (stdatomics as is called here) already serve the purpose. These > > APIs > > > > are well understood and documented. > > > > > > > > i agree that whatever atomics APIs we advocate for should align > > with > > > > the > > > > standard C atomics for the reasons you state including implied > > > > semantics. > > > > > > > > > > > > > > For environments where stdatomics are not supported, we could > > have a > > > > stdatomic.h in DPDK implementing the same APIs (we have to support > > only > > > > _explicit APIs). This allows the code to use stdatomics APIs and > > when > > > > we move to minimum supported standard C11, we just need to get rid > > of > > > > the file in DPDK repo. > > > > > > Perhaps we can use something already existing, such as this: > > > https://android.googlesource.com/platform/bionic/+/lollipop- > > release/libc/include/stdatomic.h > > > > > > > > > > > my concern with this is that if we provide a stdatomic.h or > > introduce > > > > names > > > > from stdatomic.h it's a violation of the C standard. > > > > > > > > references: > > > > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3. > > > > * GNU libc manual > > > > https://www.gnu.org/software/libc/manual/html_node/Reserved- > > > > Names.html > > > > > > > > in effect the header, the names and in some instances namespaces > > > > introduced > > > > are reserved by the implementation. there are several reasons in > > the > > > > GNU libc > > > > manual that explain the justification for these reservations and if > > > > if we think about ODR and ABI compatibility we can conceive of > > others. > > > > > > I we are going to move to C11 soon, I consider the shim interim, and > > am inclined to ignore these warning factors. > > > > > > If we are not moving to C11 soon, I would consider these > > disadvantages more seriously. > > > > I think it's reasonable to assume that we are talking years here. > > > > We've had a few discussions about minimum C standard. I think my first > > mailing list exchanges about C99 was almost 2 years ago. Given that we > > still aren't on C99 now (though i know Bruce has a series up) indicates > > that progression to C11 isn't going to happen any time soon and even if > > it was the baseline we still can't just use it (reasons described > > later). > > > > Also, i'll point out that we seem to have accepted moving to C99 with > > one of the holdback compilers technically being non-conformant but it > > isn't blocking us because it provides the subset of C99 features > > without > > being conforming that we happen to be using. > > > > > > > > > > > > > i'll also remark that the inter-mingling of names from the POSIX > > > > standard implicitly exposed as a part of the EAL public API has > > been > > > > problematic for portability. > > > > > > This is a very important remark, which should be considered > > carefully! Tyler has firsthand experience with DPDK portability. If he > > thinks porting to Windows is going to be a headache if we expose the > > stdatomic.h API, we must listen! So, what is your gut feeling here, > > Tyler? > > > > I think this is even more of a concern with language standard than it > > is > > with a platform standard. Because the language standard is used across > > platforms. > > > > On the surface it looks appealing to just go through all the dpdk code > > one last time and #include and directly depend on names > > that "look" standard. In practice though we aren't depending on the > > toolchain / libc surface we are binding ourselves to the shim and the > > implementation it provides. > > > > This is aside from the mechanics of making it work in the different > > contexts we now have to care about. Here is a story of how things > > become tricky. > > > > When i #include which one gets used if the implementation > > provides one? Let's force our stdatomic.h > > > > Now i need to force the build system to prefer my shim header? Keeping > > in mind that the presence of a libc stdatomic.h does not mean that the > > toolchain in fact supports standard atomics. Okay, that's under our > > control by editing some meson.build files maybe it isn't so bad but... > > > > It seems my application also has to do the same in their build system > > now because... > > > > The type definitions (size, alignment) and code generated from the > > body of inline functions as seen by the application built translation > > units may differ from those in the dpdk translation units if they don't > > use our header. The potential for ABI compat problems is increasing but > > maybe it is managable? it can be worse... > > > > We can't limit our scope to thinking that there is just an > > application (a single binary) and dpdk. Complex applications will > > invariably depend on other libraries and if the application needs to > > interface with those compatibily at the ABI level using standard > > atomics > > then we've made it very difficult since the application has to choose > > to > > use our conflicting named atomic types which may not be compatible or > > the real standard atomics. They can of course produce horrible shims > > of their own to interoperate. > > > > We need consistency across the entire binary at runtime and i don't > > think it's practical to say that anyone who uses dpdk has to compile > > their whole world with our shim. So dealing with all this complexity > > for the sake of asthetics "looking" like the standard api seems kind > > of not worth it. Sure it saves having to deprecate later and one last > > session of shotgun surgery but that's kind of all we get. > > > > Don't think i'm being biased in favor of windows/msvc here. From the > > perspective of the windows/msvc combination i intend to use only the > > standard C ABI provided by the implementation. I have no intention of > > trying to introduce support for the current ABI that doesn't use the > > standard atomic types. my discouraging of this approach is about > > avoiding > > subtle to detect but very painful problems on > > {linux,unix}/compiler > > combinations that already have a shipped/stable ABI. > > > > > > > > > > let's discuss this from here. if there's still overwhelming desire > > to > > > > go > > > > this route then we'll just do our best. > > > > > > > > ty > > > > > > I have a preference for exposing the stdatomic.h API. Tyler listed > > the disadvantages above. (I also have a preference for moving to C11 > > soon.) > > > > I am eager to see this happen, but as explained in my original proposal > > it doesn't eliminate the need for an abstraction. Unless we are willing > > to break our compatibility promises and potentially take a performance > > hit on some platform/compiler combinations which as i understand is not > > acceptable. > > > > > > > > Exposing a 1:1 similar API with RTE prefixes would also be acceptable > > for me. The disadvantage is that the names are different than the C11 > > names, which might lead to some confusion. And from an ABI stability > > perspective, such an important API should not be marked experimental. > > This means that years will pass before we can get rid of it again, due > > to ABI stability policies. > > > > I think the key to success with rte_ prefixed names is making > > absolutely > > sure we mirror the semantics and types in the standard. > > > > I will point out one bit of fine print here is that we will not support > > atomic operations on struct/union types (something the standard > > supports). > > With the rte_ namespace i think this becomes less ambiguous, if we > > present > > standard C names though what's to avoid the confusion? Aside from it > > fails > > to compile with one compiler vs another. > > > > I agree that this may be around for years. But how many years depends a > > lot on how long we have to maintain compatibility for the existing > > platform/compiler combinations that can't (and aren't enabled) to use > > the standard. > > > > Even if we introduced standard names we still have to undergo some kind > > of mutant deprecation process to get the world to recompile everything > > against the actual standard, so it doesn't give us forward > > compatibility. > > > > Let me know what folks would like to do, i guess i'm firmly leaned > > toward no-shim and just rte_ explicit. But as a community i'll pursue > > whatever you decide. > > > > Thanks! > > Tyler is making a very strong case here. > > I have changed my mind, and now support Tyler's approach. > Having read through the whole thread a second time, I am starting to realise how complex a problem this could be. From what I read, I would tend towards the opinion that we shouldn't provide any atomics in DPDK at all, and just rely on the C standard ones. The main complication in any solution I suspect is going to be the use of atomics in static inline functions we have in our header files. /Bruce