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 CD30BA0A0C; Wed, 30 Jun 2021 23:49:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A93D40141; Wed, 30 Jun 2021 23:49:40 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 598EF40040; Wed, 30 Jun 2021 23:49:38 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 8D53520B7178; Wed, 30 Jun 2021 14:49:37 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8D53520B7178 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1625089777; bh=n1d3acxCu1PKYZ8uCpmE1J99js8vbF6fqce0CYjAMlA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KxXDSMAMFrC968qxkYt07CCAks86JtbCpWebJqUqhvavQVD9Ms0U4ypV9OL/w95mk Xky5IYGiFUYEm92AtOutUf9RgLF3Ta4IaFXVALzsK6Ysb9jATd4x/b8EJNqg2qTwlZ 6OqCPSME8UU2R3nE9wx6R+AVyGAqpNzHAmXpNPG0= Date: Wed, 30 Jun 2021 14:49:37 -0700 From: Tyler Retzlaff To: Honnappa Nagarahalli Cc: "thomas@monjalon.net" , Joyce Kong , "dev@dpdk.org" , "david.marchand@redhat.com" , "stephen@networkplumber.org" , "olivier.matz@6wind.com" , "andrew.rybchenko@oktetlabs.ru" , "harry.van.haaren@intel.com" , Ruifeng Wang , nd , "techboard@dpdk.org" Message-ID: <20210630214937.GA15829@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210604094624.31308-1-joyce.kong@arm.com> <20210617152155.GD29777@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <7557795.l8Y19qOmnl@thomas> <20210630185107.GA14701@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20210630193822.GA21590@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] [PATCH v2 0/8] use GCC's C11 atomic builtins for test 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 Sender: "dev" On Wed, Jun 30, 2021 at 08:25:44PM +0000, Honnappa Nagarahalli wrote: > > > > > > > > As I mentioned earlier in this thread, GCC supports 2 types of > > > atomics. "Use GCC atomic builtins" does not help distinguish between > > > them. In "GCC's C11 atomic builtins" - "C11" indicates which atomics > > > we are using, "atomic builtins" indicates that we are NOT using APIs > > > from stdatomic.h > > > > if you need a term to distinguish the two sets of atomics in gcc you can qualify > > it with "Memory Model Aware" which is straight from the gcc manual. > "Memory model aware" sounds too generic. The same page [1] also makes it clear that the built-in functions match the requirements for the C11 memory model. allow me to put your interpretation of the manual that you linked side by side with what the manual text actually says verbatim. your text from above "built-in functions match the requirements for the C11 memory model." the actual text from your link "built-in functions approximately match the requirements for the C++11 memory model." * you've chosen to drop approximately from the wording to try and make your argument. * you've also chosen to substitute C11 in place of C++11. again presumably for the same reason. in fact the entire page does not mention C11 even once, it also goes on to highlight a specific deviation from C++11 with this excerpt "because of a deficiency in C++11's semantics for memory_order_consume" > There are also several patches merged in the past which do not use the term "memory model aware". I would prefer to be consistent. i prefer the history represent the change. that previous submitters and reviewers lacked precision is not my concern nor is consistency a reason to continue documenting history incorrectly. i'm waiting to ack the change, it's up to you. you've already spent more time arguing than it would have taken to submit a v2 correcting the problem. > > [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html