From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CA33C3A5A7 for ; Wed, 4 Sep 2019 12:21:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0172222CF5 for ; Wed, 4 Sep 2019 12:21:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a7mDRhy5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727083AbfIDMVP (ORCPT ); Wed, 4 Sep 2019 08:21:15 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:44228 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726495AbfIDMVP (ORCPT ); Wed, 4 Sep 2019 08:21:15 -0400 Received: by mail-ot1-f67.google.com with SMTP id 21so12914862otj.11; Wed, 04 Sep 2019 05:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rHaqVeFyBPmMJqp0NJ1A/jwQaC3tHW81qREyqlZbtWg=; b=a7mDRhy5rSIG0FnoXNs0h8NLoQ+2PLLSFCGdReAkkZdyKO2im6S723BApKIcBX9GaP k+p4Y4VNCI8Js+S4ZN+mOYxe2gliNcBcRMFZhkTARY3Zff0zorxcWvgNMWlVMeNPAEkD BmCymUYJYlH1kq93rWyjs86Wr7wk/qaP8UBDVok3S4FVtSd7AgSmFEihcae6V9skXVed DAe/BO/Db4Fa0dWxt/iwV1ILdCQxsHq6rMZq+MwagiequdCgncm93kjWAgFfjFcYisto 5rZvIfqOpo9NUZOtfQcbo52RML6tWEAZRk62e93pU145Yv6bcZYwdNd9QYDviL3AOnD1 C6kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rHaqVeFyBPmMJqp0NJ1A/jwQaC3tHW81qREyqlZbtWg=; b=HK//0sBhZaImu3iN1cZOaE5+0flmQ5zP0AOAUljB1nxPGPYBW3pQzcqMV1mZyclN80 iogtcJHPn4Rl+MahQiNpeYLcTLUEYjszbLp/iFEmaOzxknpl/v0p7O6GtWnDhvzDSMQ3 DxV5ITBh2KxXHwVgddemXH2RU9oYuYAO2nqwRMZRzkNYOHpMxI6naHtdJkODSbI+GmWb tV5MNjMK/1/4PGRxOnH1LrDiC19eqFFJHo1GghUK5k2P4oDWDkU0Ss7Cn8pUMtD+CeL2 j/Sr3JBp5tuWIpjrIFfGe2Dw7W780iZuRNbY0zhQ3r5wzaQRmXTLNoaYw3ZnlOCKIxWP 9ZaQ== X-Gm-Message-State: APjAAAUc4RupTRdBUTcWd3XKMxZHx449gigYqDV+ZT+fApvjg9GU3yp0 RlaiqEdcur18W7SvOCwKsroNQbvZfkGtDTWm6sYsYNqb X-Google-Smtp-Source: APXvYqyU0L4uckeWKAFqjUiOJk7jDNi/kZJbekGY4z9+Q7SMYSd7h5WT4LRuUnyw3C12CZXH8omvle2mYNXpl7sA9AQ= X-Received: by 2002:a9d:4e11:: with SMTP id p17mr5863173otf.192.1567599674208; Wed, 04 Sep 2019 05:21:14 -0700 (PDT) MIME-Version: 1.0 References: <1554792253-27081-1-git-send-email-magnus.karlsson@intel.com> <1554792253-27081-3-git-send-email-magnus.karlsson@intel.com> In-Reply-To: From: Magnus Karlsson Date: Wed, 4 Sep 2019 14:21:02 +0200 Message-ID: Subject: Re: [PATCH bpf 2/2] libbpf: remove dependency on barrier.h in xsk.h To: Yauheni Kaliuta Cc: Magnus Karlsson , bpf , Network Development Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Sep 4, 2019 at 2:19 PM Yauheni Kaliuta wrote: > > Hi, Magnus! > > >>>>> On Wed, 4 Sep 2019 12:25:13 +0200, Magnus Karlsson wrote: > > On Wed, Sep 4, 2019 at 8:56 AM Yauheni Kaliuta > > wrote: > >> > >> Hi, Magnus! > >> > >> >>>>> On Wed, 4 Sep 2019 08:39:24 +0200, Magnus Karlsson wrote: > >> > >> > On Wed, Sep 4, 2019 at 7:32 AM Yauheni Kaliuta > >> > wrote: > >> >> > >> >> Hi, Magnus! > >> >> > >> >> >>>>> On Tue, 9 Apr 2019 08:44:13 +0200, Magnus Karlsson wrote: > >> >> > >> >> > The use of smp_rmb() and smp_wmb() creates a Linux header dependency > >> >> > on barrier.h that is uneccessary in most parts. This patch implements > >> >> > the two small defines that are needed from barrier.h. As a bonus, the > >> >> > new implementations are faster than the default ones as they default > >> >> > to sfence and lfence for x86, while we only need a compiler barrier in > >> >> > our case. Just as it is when the same ring access code is compiled in > >> >> > the kernel. > >> >> > >> >> > Fixes: 1cad07884239 ("libbpf: add support for using AF_XDP sockets") > >> >> > Signed-off-by: Magnus Karlsson > >> >> > --- > >> >> > tools/lib/bpf/xsk.h | 19 +++++++++++++++++-- > >> >> > 1 file changed, 17 insertions(+), 2 deletions(-) > >> >> > >> >> > diff --git a/tools/lib/bpf/xsk.h b/tools/lib/bpf/xsk.h > >> >> > index 3638147..317b44f 100644 > >> >> > --- a/tools/lib/bpf/xsk.h > >> >> > +++ b/tools/lib/bpf/xsk.h > >> >> > @@ -39,6 +39,21 @@ DEFINE_XSK_RING(xsk_ring_cons); > >> >> > struct xsk_umem; > >> >> > struct xsk_socket; > >> >> > >> >> > +#if !defined bpf_smp_rmb && !defined bpf_smp_wmb > >> >> > +# if defined(__i386__) || defined(__x86_64__) > >> >> > +# define bpf_smp_rmb() asm volatile("" : : : "memory") > >> >> > +# define bpf_smp_wmb() asm volatile("" : : : "memory") > >> >> > +# elif defined(__aarch64__) > >> >> > +# define bpf_smp_rmb() asm volatile("dmb ishld" : : : "memory") > >> >> > +# define bpf_smp_wmb() asm volatile("dmb ishst" : : : "memory") > >> >> > +# elif defined(__arm__) > >> >> > +# define bpf_smp_rmb() asm volatile("dmb ish" : : : "memory") > >> >> > +# define bpf_smp_wmb() asm volatile("dmb ishst" : : : "memory") > >> >> > +# else > >> >> > +# error Architecture not supported by the XDP socket code in libbpf. > >> >> > +# endif > >> >> > +#endif > >> >> > + > >> >> > >> >> What about other architectures then? > >> > >> > AF_XDP has not been tested on anything else, as far as I > >> > know. But contributions that extend it to more archs are > >> > very welcome. > >> > >> Well, I'll may be try to fetch something from barrier.h's > >> (since I cannot consider myself as a specialist in the area), > >> but at the moment the patch breaks the build on that arches. > > > Do you have a specific architecture in mind and do you have > > some board/server (of that architecture) you could test AF_XDP > > on? > > I do care about s390 and ppc64 and I can run tests for them. Perfect!. Thanks. /Magnus > > [...] > > -- > WBR, > Yauheni Kaliuta