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 B73B341BC0; Fri, 3 Feb 2023 21:49:14 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6A40D40EDF; Fri, 3 Feb 2023 21:49:14 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 3EDA440ED4 for ; Fri, 3 Feb 2023 21:49:13 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 628BD208620F; Fri, 3 Feb 2023 12:49:12 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 628BD208620F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1675457352; bh=7tkS0ZGDbQQBiXIA1GYuPvu05ogSR9GlS4xkwkRjonU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nQyu4sENGzQIHnpTto1XWtt8tgMV9rxrpfYt72Ba2Mgc+Ifz9znHIQx41WF7Wu7QO tsgXo+mFgHydjewuy3/G3sPXIR24tlRZ98SzD2JboFn937rBs81fV5YkiihgCbQgLY HrQmWXK9TlSImzwB+tPVJFQnQZSRyfSONpImBgF4= Date: Fri, 3 Feb 2023 12:49:12 -0800 From: Tyler Retzlaff To: Bruce Richardson Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Honnappa Nagarahalli , thomas@monjalon.net, dev@dpdk.org, david.marchand@redhat.com, jerinj@marvell.com, konstantin.ananyev@huawei.com, ferruh.yigit@amd.com, nd Subject: Re: [PATCH] eal: introduce atomics abstraction Message-ID: <20230203204912.GA4631@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Fri, Feb 03, 2023 at 12:19:13PM +0000, Bruce Richardson wrote: > On Thu, Feb 02, 2023 at 11:00:23AM -0800, Tyler Retzlaff wrote: > > 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. > > > What compiler is this? As far as I know, all our currently support > compilers claim to support C99 fully. All should support C11 also, > except for GCC 4.8 on RHEL/CentOS 7. Once we drop support for Centos 7, I > think we can require at minimum a c11 compiler for building DPDK itself. > I'm still a little uncertain about requiring that users build their own > code with -std=c11, though. perhaps i'm mistaken but it was my understanding that the gcc version on RHEL 7 did not fully conform to C99? maybe i read C99 when it was actually C11. regardless, even if every supported compiler for dpdk was C11 conformant including stdatomics which are optional we can't just move from intrinsic/builtins to standard C atomics (because of the compatibility and performance issues mentioned previously). so just re-orienting this discussion, the purpose of this abstraction is to allow the optional use of standard C atomics when a conformant compiler is available and satisfactory code is generated for the desired target. > > /Bruce