From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v2] ring: enforce reading the tails before
	ring operations
Date: Sat, 09 Mar 2019 00:18:08 +0100
Message-ID: <2456717.RLOWIjrx09@xps>
References: <1551841661-42892-1-git-send-email-gavin.hu@arm.com>
 <VI1PR08MB31670DE4179E1194F5410D428F4D0@VI1PR08MB3167.eurprd08.prod.outlook.com>
 <2601191342CEEE43887BDE71AB9772580136556F40@irsmsx105.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Ilya Maximets <i.maximets@samsung.com>, "dev@dpdk.org" <dev@dpdk.org>,
 nd <nd@arm.com>, "jerinj@marvell.com" <jerinj@marvell.com>,
 "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
 "Nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
 Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
 "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "Richardson,
 Bruce" <bruce.richardson@intel.com>,
 "chaozhu@linux.vnet.ibm.com" <chaozhu@linux.vnet.ibm.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id AC206A3
 for <dev@dpdk.org>; Sat,  9 Mar 2019 00:19:49 +0100 (CET)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580136556F40@irsmsx105.ger.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

08/03/2019 16:50, Ananyev, Konstantin:
> 08/03/2019 16:05, Gavin Hu (Arm Technology China):
> > Anyway, on x86, smp_rmb, as a compiler barrier, applies to load/store, not only load/load.
> 
> Yes, that's true, but I think that's happened by coincidence, 
> not intentionally.
> 
> > This is the case also for arm, arm64, ppc32, ppc64.
> > I will submit a patch to expand the definition of this API.
> 
> I understand your intention, but that does mean we would also need
> to change not only rte_smp_rmb() but rte_rmb() too (to keep things consistent)?
> That sounds worring.  
> Might be better to keep smp_rmb() definition as it is, and introduce new function
> that fits your purposes (smp_rwmb or smp_load_store_barrier)?

How is it managed in other projects?