From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Ananyev, Konstantin" <konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 02/12] Add atomic operations for IBM
	Power	architecture
Date: Thu, 16 Oct 2014 00:39:52 +0000
Message-ID: <2601191342CEEE43887BDE71AB97725821393C8F@IRSMSX105.ger.corp.intel.com>
References: <1411724186-8036-1-git-send-email-bjzhuc@cn.ibm.com>
 <1411724186-8036-3-git-send-email-bjzhuc@cn.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
To: Chao Zhu <bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>, "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Return-path: <dev-bounces-VfR2kkLFssw@public.gmane.org>
In-Reply-To: <1411724186-8036-3-git-send-email-bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>
Content-Language: en-US
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev-VfR2kkLFssw@public.gmane.org>
List-Help: <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request-VfR2kkLFssw@public.gmane.org?subject=subscribe>
Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org
Sender: "dev" <dev-bounces-VfR2kkLFssw@public.gmane.org>


Hi,

> -----Original Message-----
> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Chao Zhu
> Sent: Friday, September 26, 2014 10:36 AM
> To: dev-VfR2kkLFssw@public.gmane.org
> Subject: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power arc=
hitecture
>=20
> The atomic operations implemented with assembly code in DPDK only
> support x86. This patch add architecture specific atomic operations for
> IBM Power architecture.
>=20
> Signed-off-by: Chao Zhu <bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>
> ---
>  .../common/include/powerpc/arch/rte_atomic.h       |  387 ++++++++++++++=
++++++
>  .../common/include/powerpc/arch/rte_atomic_arch.h  |  318 ++++++++++++++=
++
>  2 files changed, 705 insertions(+), 0 deletions(-)
>  create mode 100644 lib/librte_eal/common/include/powerpc/arch/rte_atomic=
.h
>  create mode 100644 lib/librte_eal/common/include/powerpc/arch/rte_atomic=
_arch.h
>=20
...
> +
> diff --git a/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h
> b/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h
> new file mode 100644
> index 0000000..fe5666e
> --- /dev/null
> +
...
>+#define	rte_arch_rmb() asm volatile("sync" : : : "memory")
>+
> +#define	rte_arch_compiler_barrier() do {		\
> +	asm volatile ("" : : : "memory");	\
> +} while(0)

I don't know much about PPC architecture, but as I remember it uses a  weak=
ly-ordering memory model.
Is that correct?
If so, then you probably need rte_arch_compiler_barrier() to be "sync" inst=
ruction (like mb()s above) .
The reason is that IA has much stronger memory ordering model and there are=
 a lot of places in the code where it implies that  ordering.
For example - ring enqueue/dequeue functions.=09

Konstantin