From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH 08/28] eal/arm64: define smp barrier
 definition for arm64
Date: Thu, 15 Dec 2016 13:50:43 +0530
Message-ID: <20161215082042.GA30792@localhost.localdomain>
References: <1481680558-4003-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <1481680558-4003-9-git-send-email-jerin.jacob@caviumnetworks.com>
 <CAP4Qi38SCGZHAybjiR4=hhvZbEEnjmCVGWb23+EgqjzAowmAiQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: <dev@dpdk.org>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Thomas Monjalon <thomas.monjalon@6wind.com>, Bruce Richardson
 <bruce.richardson@intel.com>, Jan Viktorin <viktorin@rehivetech.com>
To: Jianbo Liu <jianbo.liu@linaro.org>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-BY2-obe.outbound.protection.outlook.com
 (mail-by2nam01on0049.outbound.protection.outlook.com [104.47.34.49])
 by dpdk.org (Postfix) with ESMTP id 983BE36E
 for <dev@dpdk.org>; Thu, 15 Dec 2016 09:21:06 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <CAP4Qi38SCGZHAybjiR4=hhvZbEEnjmCVGWb23+EgqjzAowmAiQ@mail.gmail.com>
List-Id: DPDK patches and discussions <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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Thu, Dec 15, 2016 at 04:13:33PM +0800, Jianbo Liu wrote:
> On 14 December 2016 at 09:55, Jerin Jacob
> <jerin.jacob@caviumnetworks.com> wrote:
> > dmb instruction based barrier is used for smp version of memory barrier.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> >  lib/librte_eal/common/include/arch/arm/rte_atomic_64.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > index bc7de64..78ebea2 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
> > @@ -82,11 +82,11 @@ static inline void rte_rmb(void)
> >         dsb(ld);
> >  }
> >
> > -#define rte_smp_mb() rte_mb()
> > +#define rte_smp_mb() dmb(ish)
> >
> > -#define rte_smp_wmb() rte_wmb()
> > +#define rte_smp_wmb() dmb(ishst)
> >
> > -#define rte_smp_rmb() rte_rmb()
> > +#define rte_smp_rmb() dmb(ishld)
> >
> 
> rte_*mb are inline functions, while rte_smp_*mb are macro. As they are
> all derived from dsb/dmb, can you keep them consistent?

OK.I will add a separate patch in v2 series to change existing inline to
marco to keep consistent.


> 
> >  #ifdef __cplusplus
> >  }
> > --
> > 2.5.5
> >