From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [PATCH bpf-next 2/3] tools, perf: use smp_{rmb,mb} barriers
 instead of {rmb,mb}
Date: Thu, 18 Oct 2018 08:33:09 -0700
Message-ID: <20181018153307.ayvmq6du3gnsyvro@ast-mbp.dhcp.thefacebook.com>
References: <20181017144156.16639-1-daniel@iogearbox.net>
 <20181017144156.16639-3-daniel@iogearbox.net>
 <20181017155050.GM3121@hirez.programming.kicks-ass.net>
 <55f86215-44a8-2bb8-b1d0-a77a142dc697@iogearbox.net>
 <20181018081434.GT3121@hirez.programming.kicks-ass.net>
 <df1da9c7-f9b4-a482-0bbc-a6455b57a476@iogearbox.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Peter Zijlstra <peterz@infradead.org>, paulmck@linux.vnet.ibm.com,
        will.deacon@arm.com, acme@redhat.com, yhs@fb.com,
        john.fastabend@gmail.com, netdev@vger.kernel.org
To: Daniel Borkmann <daniel@iogearbox.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pl1-f193.google.com ([209.85.214.193]:34885 "EHLO
        mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727757AbeJRXeq (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 18 Oct 2018 19:34:46 -0400
Received: by mail-pl1-f193.google.com with SMTP id f8-v6so14508158plb.2
        for <netdev@vger.kernel.org>; Thu, 18 Oct 2018 08:33:14 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <df1da9c7-f9b4-a482-0bbc-a6455b57a476@iogearbox.net>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
>  #endif /* _TOOLS_LINUX_ASM_IA64_BARRIER_H */
> diff --git a/tools/arch/powerpc/include/asm/barrier.h b/tools/arch/powerpc/include/asm/barrier.h
> index a634da0..905a2c6 100644
> --- a/tools/arch/powerpc/include/asm/barrier.h
> +++ b/tools/arch/powerpc/include/asm/barrier.h
> @@ -27,4 +27,20 @@
>  #define rmb()  __asm__ __volatile__ ("sync" : : : "memory")
>  #define wmb()  __asm__ __volatile__ ("sync" : : : "memory")
> 
> +#if defined(__powerpc64__)
> +#define smp_lwsync()	__asm__ __volatile__ ("lwsync" : : : "memory")
> +
> +#define smp_store_release(p, v)			\
> +do {						\
> +	smp_lwsync();				\
> +	WRITE_ONCE(*p, v);			\
> +} while (0)
> +
> +#define smp_load_acquire(p)			\
> +({						\
> +	typeof(*p) ___p1 = READ_ONCE(*p);	\
> +	smp_lwsync();				\
> +	___p1;					\

I don't like this proliferation of asm.
Why do we think that we can do better job than compiler?
can we please use gcc builtins instead?
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
__atomic_load_n(ptr, __ATOMIC_ACQUIRE);
__atomic_store_n(ptr, val, __ATOMIC_RELEASE);
are done specifically for this use case if I'm not mistaken.
I think it pays to learn what compiler provides.