From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH 02/34]bnx2x: Barriers for the compiler Date: Sat, 17 Jan 2009 23:25:45 -0800 (PST) Message-ID: <20090117.232545.32388782.davem@davemloft.net> References: <1231951364.11301.123.camel@lb-tlvb-eliezer> <20090114.131356.63668949.davem@davemloft.net> <1232013057.4971.8.camel@lb-tlvb-eliezer> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: eilong@broadcom.com Return-path: Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:33478 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1759892AbZARHZo (ORCPT ); Sun, 18 Jan 2009 02:25:44 -0500 In-Reply-To: <1232013057.4971.8.camel@lb-tlvb-eliezer> Sender: netdev-owner@vger.kernel.org List-ID: From: "Eilon Greenstein" Date: Thu, 15 Jan 2009 11:50:57 +0200 > On Wed, 2009-01-14 at 13:13 -0800, David Miller wrote: > > From: "Eilon Greenstein" > > Date: Wed, 14 Jan 2009 18:42:44 +0200 > > > > > To make sure no swapping are made by the compiler, changed HAS_WORK to inline > > > functions and added all the necessary barriers > > > > > > Signed-off-by: Eilon Greenstein > > > > Don't you need cpu memory barriers too? What if the cpu reorders what > > you're trying to order using just a compiler barrier? > > > The CPU memory barriers are in place (actually, they needed some fixing, > but that was in another patch) - this one is just for the compiler and > after reviewing it again now, I still believe that it is sufficient. I > need the current executing CPU to take the right decision based on what > it currently knows - synchronization between CPUs and HW is using CPU > memory barrier. > > IMHO this patch is correct. Fair enough, applied.