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 59FE2427F6; Tue, 28 Mar 2023 20:46:10 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E7B664161A; Tue, 28 Mar 2023 20:46:09 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 661814021D for ; Tue, 28 Mar 2023 20:46:08 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 6B25620FDA86; Tue, 28 Mar 2023 11:46:07 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6B25620FDA86 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1680029167; bh=5EjHwAZLWccHM6m290tlBnG8w12qb1iJ+KZxipDdSoA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=j7MpMF0FOKCq/i7y43qwUIRCpsxocNNfM5cCQatFMBz/aCS+q+zcwMcBZLAhYAIAA E9dncu+ViJo5SB7XuK7dYpYeLX7hq5FktvlTiHSGUjL47qOW4DBG749k4pJwtX22q7 RWl+8H/PdOy6s9atjz6GTb9VByUJJYC2OH0Asd/0= Date: Tue, 28 Mar 2023 11:46:07 -0700 From: Tyler Retzlaff To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, Honnappa.Nagarahalli@arm.com, Ruifeng.Wang@arm.com, thomas@monjalon.net Subject: Re: rte_atomic API compatibility & standard atomics Message-ID: <20230328184607.GA19745@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230327193915.GA2780@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87811@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87811@smartserver.smartshare.dk> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Mar 27, 2023 at 10:08:10PM +0200, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Monday, 27 March 2023 21.39 > > > > Hi folks, > > > > 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? > > > > 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. > > > > 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. > > > > The options seem to be as follows. > > > > 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. > > > > 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. > > > > 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. > > > > Are there any other options i'm missing here? > > > > 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; > it's a good suggestion. but i'm not sure i want to get bogged down making an old api available that hopefully we will remove soon. though i'm still torn because i would really like the path to use msvc for any application to be lower burden. unless there are objections i think i'll do 2 as is. if good progress is made we can re-evaluate doing the extra work to make available the old apis as you suggest or potentially leave them unavailable forever subject to any plans to deprecate and remove them. thanks!