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 CD4E842398;
	Mon,  9 Jan 2023 23:56:07 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 707CB40689;
	Mon,  9 Jan 2023 23:56:07 +0100 (CET)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
 by mails.dpdk.org (Postfix) with ESMTP id C5B5540150
 for <dev@dpdk.org>; Mon,  9 Jan 2023 23:56:05 +0100 (CET)
Received: by linux.microsoft.com (Postfix, from userid 1086)
 id CB6302021525; Mon,  9 Jan 2023 14:56:04 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com CB6302021525
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
 s=default; t=1673304964;
 bh=tiHAslhZSvMA7j4Rci6MDkxyvHKwG8ge4CRSlSYYXso=;
 h=Date:From:To:Subject:From;
 b=W0J7OUr9H/jCk0NDqbZC93f677OaRPpgaZxMmR+owgfLxmBFI3DzxdAK561AV17Yx
 tkvCFavsvzH4muQI08X1kp2XSvSsJiLzzSr4YurJisH9DObBGvp9oht32/bq8BHDKV
 dmOeRCYnK2T1rdaDLuds+m/SGTu9LrbrquKAhWHg=
Date: Mon, 9 Jan 2023 14:56:04 -0800
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: dev@dpdk.org
Subject: RFC abstracting atomics
Message-ID: <20230109225604.GA25566@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
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

hi folks,

i would like to introduce a layer of abstraction that would allow
optional use of standard C11 atomics when the platform / toolchain
combination has them available.

making the option usable would be a phased approach intended to focus
review and minimize dealing with churn on such a broad change.

1. provide an initial series to add the abstraction and the ability
   control enablement with a meson option enable_stdatomics=false will
   be the default.

   for all existing platform / toolchain combinations the default would
   remain false. i.e. i have no plans to enable it for existing platforms
   toolchain combinations but leaves a change of default open to the
   community as a future discussion if it is desired.

2. once the initial abstraction is integrated a series will be introduced to
   port the tree to the abstraction with enable_stdatomics=false. the goal
   being low or no change to the current use of gcc builtin C++11 memory
   model atomics.

3. once the tree is ported a final series will be introduced to introduce
   the remaining change to allow the use of enable_stdatomics=true.

would appreciate any assistance / suggestions you can provide to
introduce the abstraction smoothly.

thanks