From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viktorin@rehivetech.com>
Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16])
 by dpdk.org (Postfix) with ESMTP id 1BC9C37AF
 for <dev@dpdk.org>; Mon,  2 Nov 2015 14:12:10 +0100 (CET)
Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz
 [147.229.13.147])
 by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3nqF5P50HvzBjW;
 Mon,  2 Nov 2015 14:12:09 +0100 (CET)
Date: Mon, 2 Nov 2015 14:10:28 +0100
From: Jan Viktorin <viktorin@rehivetech.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Message-ID: <20151102141028.7b58007e@pcviktorin.fit.vutbr.cz>
In-Reply-To: <20151102055304.GB17659@localhost.localdomain>
References: <5289220.BuGOiUSaJq@xps13>
 <1446164742-29546-1-git-send-email-viktorin@rehivetech.com>
 <1446164742-29546-2-git-send-email-viktorin@rehivetech.com>
 <20151102055304.GB17659@localhost.localdomain>
Organization: RehiveTech
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Vlastimil Kosar <kosar@rehivetech.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v5 01/15] eal/arm: atomic operations for ARM
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: Mon, 02 Nov 2015 13:12:10 -0000

On Mon, 2 Nov 2015 11:23:05 +0530
Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:

--snip--
> > +#ifndef _RTE_ATOMIC_ARM_H_
> > +#define _RTE_ATOMIC_ARM_H_
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include "generic/rte_atomic.h"
> > +
> > +/**
> > + * General memory barrier.
> > + *
> > + * Guarantees that the LOAD and STORE operations generated before the
> > + * barrier occur before the LOAD and STORE operations generated after.
> > + */
> > +#define	rte_mb()  __sync_synchronize()
> > +
> > +/**
> > + * Write memory barrier.
> > + *
> > + * Guarantees that the STORE operations generated before the barrier
> > + * occur before the STORE operations generated after.
> > + */
> > +#define	rte_wmb() do { asm volatile ("dmb st" : : : "memory"); } while (0)
> > +
> > +/**
> > + * Read memory barrier.
> > + *
> > + * Guarantees that the LOAD operations generated before the barrier
> > + * occur before the LOAD operations generated after.
> > + */
> > +#define	rte_rmb() __sync_synchronize()
> > +  
> 
> #define dmb(opt)        asm volatile("dmb " #opt : : : "memory")
> 
> static inline void rte_mb(void)
> {
>         dmb(ish);
> }
> 
> static inline void rte_wmb(void)
> {
>         dmb(ishst);
> }
> 
> static inline void rte_rmb(void)
> {
>         dmb(ishld);

I cannot see this option in the doc for ARMv7
(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0588b/CIHGHHIE.html).

> }
> 
> For armv8, it make sense to have above definition for rte_*mb().

If it is OK to restrict the barriers to the inner-domain then OK. Quite
frankly, I don't know.

> If doesn't make sense for armv7 then we need split this file rte_atomic_32/64.h
> 
> 


-- 
   Jan Viktorin                  E-mail: Viktorin@RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic