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 7AD3042854; Mon, 27 Mar 2023 22:08:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A86041140; Mon, 27 Mar 2023 22:08:14 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 52BDB410D0 for ; Mon, 27 Mar 2023 22:08:13 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: rte_atomic API compatibility & standard atomics Date: Mon, 27 Mar 2023 22:08:10 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87811@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20230327193915.GA2780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rte_atomic API compatibility & standard atomics Thread-Index: Adlg49Qhay9UPQIDScWiTpnwtOppKAAAjTlQ References: <20230327193915.GA2780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , , , , 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 > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Monday, 27 March 2023 21.39 >=20 > Hi folks, >=20 > I don't think we discussed it specifically but what is the expectation > in relation to converting to standard atomics and compatibility of the > legacy rte_atomic APIs? >=20 > We can't really convert the inline function implementations of the > rte_atomic APIs because doing so would break compatibility. This is > because if the implementation uses standard atomics APIs then we are > required to pass _Atomic types to the generic atomic intrinsics. >=20 > We can choose to just leave the rte_atomic API implementations as they > are using the GCC builtins and i'm fine with that, but I do need some > help with what to do with msvc then since it doesn't have those > builtins. >=20 > The options seem to be as follows. >=20 > 1. > Just cast the non-atomic types in the rte_atomic APIs implementation > to _Atomic which may work but i'm pretty sure is undefined behavior > since > you can't qualify a non _Atomic type to suddenly be _Atomic. >=20 > 2. > We could conditionally compile (hide) the legacy rte_atomic APIs when > msvc is in use, this seems not bad since there technically aren't any > Windows/MSVC consumers, but if someone wanted to port an existing > application they would have to adapt the code to avoid use of > rte_atomic. >=20 > For now I think the safest option is to go with 2 since it doesn't > impose any compatibility risk and conditional compilation only exists > until we deprecate and remove the old rte_atomic APIs. >=20 > Are there any other options i'm missing here? >=20 > Thanks As a variant of your second option, you could make most of the legacy = rte_atomic APIs available to MSVC by changing the atomic counter types = from volatile to _Atomic. Then only the atomic cmpset() and exchange() = functions are unavailable for the application. E.g. for the 32 bit = atomic counter type: typedef struct { - volatile int32_t cnt; /**< An internal counter value. */ + _Atomic int32_t cnt; /**< An internal counter value. */ } rte_atomic32_t;