From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id DEF695F17; Tue, 9 Oct 2018 10:53:12 +0200 (CEST) Received: from rsa59-2-82-233-193-189.fbx.proxad.net ([82.233.193.189] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1g9nmS-0003gR-Ug; Tue, 09 Oct 2018 10:54:18 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Tue, 09 Oct 2018 10:53:03 +0200 Date: Tue, 9 Oct 2018 10:53:03 +0200 From: Olivier Matz To: Ola Liljedahl Cc: Jerin Jacob , "dev@dpdk.org" , Honnappa Nagarahalli , "Ananyev, Konstantin" , "Gavin Hu (Arm Technology China)" , Steve Capper , nd , "stable@dpdk.org" Message-ID: <20181009085303.tqzojba7k7ung3h5@platinum> References: <063A95EC-CFC1-42F7-B864-DFB9C6718AC8@arm.com> <20181008100004.GB11081@jerin> <20181008104653.GC11081@jerin> <20181008115028.GA28968@jerin> <22595D8F-00A6-4D45-B143-2BF25148869D@arm.com> <20181008120524.GC28968@jerin> <20181008122038.GD28968@jerin> <23972B4A-8A0D-4837-97D9-EA8F735A1F26@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23972B4A-8A0D-4837-97D9-EA8F735A1F26@arm.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v3 1/3] ring: read tail using atomic load X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 08:53:13 -0000 Hi, On Mon, Oct 08, 2018 at 12:30:15PM +0000, Ola Liljedahl wrote: > > > On 08/10/2018, 14:21, "Jerin Jacob" wrote: > > -----Original Message----- > > Date: Mon, 8 Oct 2018 17:35:25 +0530 > > From: Jerin Jacob > > To: Ola Liljedahl > > CC: "dev@dpdk.org" , Honnappa Nagarahalli > > , "Ananyev, Konstantin" > > , "Gavin Hu (Arm Technology China)" > > , Steve Capper , nd , > > "stable@dpdk.org" > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] ring: read tail using atomic load > > User-Agent: Mutt/1.10.1 (2018-07-13) > > > > External Email > > > > -----Original Message----- > > > Date: Mon, 8 Oct 2018 11:59:16 +0000 > > > From: Ola Liljedahl > > > To: Jerin Jacob > > > CC: "dev@dpdk.org" , Honnappa Nagarahalli > > > , "Ananyev, Konstantin" > > > , "Gavin Hu (Arm Technology China)" > > > , Steve Capper , nd , > > > "stable@dpdk.org" > > > Subject: Re: [PATCH v3 1/3] ring: read tail using atomic load > > > user-agent: Microsoft-MacOutlook/10.11.0.180909 > > > > > > > > > On 08/10/2018, 13:50, "Jerin Jacob" wrote: > > > > > > > > > I don't know how that creates more undefined behavior. So replied in the > > > context of your reply that, according to your view even Linux is running > > > with undefined behavior. > > > > > > As I explained, Linux does not use C11 atomics (nor GCC __atomic builtins) so > > > cannot express the kind of undefined behaviour caused by mixing conflicting atomic > > > (as defined by the C11 standard) and non-atomic accesses to the same object. > > > > > > Checked the latest version from https://github.com/torvalds/linux > > > > Yet another top post. So you removed the complete earlier context. Never > > mind. > Top post? My reply is under your text. As is this. > > Don't blame my stupid mail agent on your misunderstanding of C11. Sorry, but honnestly, your mail agent configuration makes the thread harder to read for many people. > > I am not saying Linux is using C11 atomic. I asked, Can't we follow > > like Linux to use the HW feature of load acquire and store release > > semantics with introducing C11 memory model. > > correction: > > s/with introducing C11 memory model/with out introducing C11 memory model > You can generate e.g. AArch64/A64 LDAR and STLR instructions using inline assembler. > But you won't be able to specify acquire and release ordering to the compiler, so you > must specify a full memory barrier instead. > > But why create a C11-like but custom DPDK specific memory model when the compiler > already supports a standardised, well defined and tested memory model? You would just be > creating a mountain of technical debt. Let's try to sumarize my understanding of the discussion: - mixing standard access and C11-like access is undefined according to the C11 specification. However it works today with current compilers and hw. - the patch does not fix any identified issue, but it can make the code more consistent by using C11 access. - with the patch, one "add" instruction is added. The impact is difficult to measure, but it is expected to be smaller than the noise generated by a code alignment change. I'm unfortunately not an expert about C11 atomic memory model. But, if it is more consistent with the rest of the code and if we cannot detect any performance impact, well, I think it could go in. Regards, Olivier