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 880C142853; Mon, 27 Mar 2023 21:39:18 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1583F41140; Mon, 27 Mar 2023 21:39:18 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 45DF6410D0 for ; Mon, 27 Mar 2023 21:39:16 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 8275C20FD084; Mon, 27 Mar 2023 12:39:15 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8275C20FD084 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1679945955; bh=oMjSL7kM9BSXWE341cSyipEs8tEzjhThuVAkU3/8cTQ=; h=Date:From:To:Subject:From; b=dQLkxnDsJcF/xkR2JmytY/XT+e8sHmQPsupdihcEj4dcMds2aKvWNPj5Of60GAHm0 zo7O2OEThai1HEfYdU6IgPCw6E3b0NVEvadGsC3vHKJk7mWZrHKrbO9Z+jDS3cV1+U UqkLdejNuldWMaZvUGsZfaYHxG7hbZnPb/Dcnwzk= Date: Mon, 27 Mar 2023 12:39:15 -0700 From: Tyler Retzlaff To: dev@dpdk.org, mb@smartsharesystems.com, Honnappa.Nagarahalli@arm.com, Ruifeng.Wang@arm.com, thomas@monjalon.net Subject: rte_atomic API compatibility & standard atomics Message-ID: <20230327193915.GA2780@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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