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 86C1819F5 for ; Mon, 11 Jul 2016 13:40:34 +0200 (CEST) Received: from lfbn-1-8274-170.w81-254.abo.wanadoo.fr ([81.254.171.170] helo=[192.168.1.13]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bMZc2-0002pg-Ad; Mon, 11 Jul 2016 13:43:06 +0200 To: "Kuusisaari, Juhamatti" , "Ananyev, Konstantin" , "dev@dpdk.org" References: <20160711102055.14855-1-juhamatti.kuusisaari@coriant.com> <2601191342CEEE43887BDE71AB97725836B7C858@irsmsx105.ger.corp.intel.com> From: Olivier Matz Message-ID: <5837bceb-070e-76d4-d548-8d5e9f1cce32@6wind.com> Date: Mon, 11 Jul 2016 13:40:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct location X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 11:40:34 -0000 Hi, On 07/11/2016 01:22 PM, Kuusisaari, Juhamatti wrote: > > Hi, > >>> -----Original Message----- >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Juhamatti >>> Kuusisaari >>> Sent: Monday, July 11, 2016 11:21 AM >>> To: dev@dpdk.org >>> Subject: [dpdk-dev] [PATCH] lib: move rte_ring read barrier to correct >>> location >>> >>> Fix the location of the rte_ring data dependency read barrier. >>> It needs to be called before accessing indexed data to ensure that the >>> data itself is guaranteed to be correctly updated. >>> >>> See more details at kernel/Documentation/memory-barriers.txt >>> section 'Data dependency barriers'. >> >> >> Any explanation why? >> From my point smp_rmb()s are on the proper places here :) Konstantin > > The problem here is that on a weak memory model system the CPU is > allowed to load the address data out-of-order in advance. > If the read barrier is after the DEQUEUE, you might end up having the old > data there on a race situation when the buffer is continuously full. > Having it before the DEQUEUE guarantees that the load is not done > in advance. > > On Intel, it should not matter due to different memory model, so this is > limited to weak memory model systems. I agree with Juhamatti. To me, the reading of consumer_head must occur before the reading of objects ptrs. That was the case before, and this is something I already noticed when I sent that mail: http://dpdk.org/ml/archives/dev/2014-March/001742.html At that time, only Intel CPUs were supported, so it did not make any difference. Juhamatti, do you have a setup where you can trigger the issue or is it something you've seen by code review? Thanks, Olivier