From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com
 [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id 2DCE458DD
 for <dev@dpdk.org>; Thu, 27 Mar 2014 21:18:43 +0100 (CET)
Received: by mail-pd0-f172.google.com with SMTP id p10so3830590pdj.31
 for <dev@dpdk.org>; Thu, 27 Mar 2014 13:20:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-type:content-transfer-encoding;
 bh=cTIFLQ7SoeVQVtr8tyvyT3MI/arj+zAzB52j3sWEZh8=;
 b=bUfTtw58JwSRZG8g1cKpz2uyCW7XmwoGRZLWKxmXiEjjldXiDquh5Wg3VQXEK3/5wf
 xieMf0DOTKPTyIGjU1uLCr1/XcSFUbLs2BZTJLA66p6oEyEYShdvwQOG2+mkn5yLQ3Ea
 +dVH2OI6RKK7y2mQeKCGOs/ZPtcPMxKNRt5IyKYqqXFthNcbMoSXls4jHIqtsR5V3UfN
 vFbc0EPFXFvfIzR5vCCu+ia+OydSNLYT4VwfEfA30yDE0VB/E2FPh9t4CHmX25Q1slwB
 n93zbJ5c+6qbX/Cmn/b4xGxJbjHJBj7TWPrl+ntN8yj9Xr5nv1HmppMMLHoaXNP54g6s
 hvQA==
X-Gm-Message-State: ALoCoQnaYwpsS7GJgNniMgBtV0GY4IfEywDVjw1lLat9k57I1OpveK+UPz1uooCTQGx5C+9ooEus
X-Received: by 10.66.136.131 with SMTP id qa3mr3909282pab.77.1395951617533;
 Thu, 27 Mar 2014 13:20:17 -0700 (PDT)
Received: from samsung-9 ([172.56.38.58])
 by mx.google.com with ESMTPSA id hw8sm12989552pbc.62.2014.03.27.13.20.16
 for <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 27 Mar 2014 13:20:17 -0700 (PDT)
Date: Thu, 27 Mar 2014 13:20:13 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Olivier MATZ <olivier.matz@6wind.com>
Message-ID: <20140327132013.10011e6a@samsung-9>
In-Reply-To: <53348059.6000505@6wind.com>
References: <53345655.9030907@6wind.com> <20140327120620.07f1496b@samsung-9>
 <53348059.6000505@6wind.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] memory barriers in rte_ring
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 20:18:44 -0000

On Thu, 27 Mar 2014 20:47:37 +0100
Olivier MATZ <olivier.matz@6wind.com> wrote:

> Hi Stephen,
> 
> On 03/27/2014 08:06 PM, Stephen Hemminger wrote:
> > Long answer: for the multple CPU access ring, it is equivalent to smp_wmb and smp_rmb
> >   in Linux kernel. For x86 where DPDK is used, this can normally be replaced by simpler
> >   compiler barrier. In kernel there is a special flage X86_OOSTORE which is only enabled
> >   for a few special cases, for most cases it is not. When cpu doesnt do out of order
> >   stores, there are no cases where other cpu will see wrong state.
> 
> Thank you for this clarification.
> 
> So, if I understand properly, all usages of rte_*mb() sequencing memory
> operations between CPUs could be replaced by a compiler barrier. On the
> other hand, if the memory is also accessed by a device, a memory
> barrier has to be used.
> 
> Olivier
> 

I think so for the current architecture that DPDK runs on. It might be good
to abstract this in some way for eventual users in other environments.