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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 19088C282C2 for ; Wed, 13 Feb 2019 11:33:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DB7582073D for ; Wed, 13 Feb 2019 11:33:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jJ28DOyF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732543AbfBMLc7 (ORCPT ); Wed, 13 Feb 2019 06:32:59 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:35613 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbfBMLc7 (ORCPT ); Wed, 13 Feb 2019 06:32:59 -0500 Received: by mail-ot1-f67.google.com with SMTP id z19so3374467otm.2 for ; Wed, 13 Feb 2019 03:32:58 -0800 (PST) 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=MoDfDlaidAPuXBw9rdIhpM30CZohZUs73tZCKrQ+vZw=; b=jJ28DOyFoIVZWXtFzM/XWUKESKSZQ76WyIsW8nrvGkLAggab4dVHNsWkKwHP0ziFr/ yfg2YFkh/+TdB4IJXlkqFmkVltLchdyGPKmJp++R/LpQh5ixdzjEJLw8IyjNbKwWeWPM FlB8LNzAPZMiZ3smSNqN0AOsW2+w91aHvU9UDHcxqgTSjSBWpfShN8FtyfFwi167uZaj x1TyK2IkEPGKXB17zE5YDk8sa6L6vy0NnSxJEWYg4nUcvy0bQSSVfUjeheRA2BGWQ7Ro vYs1+Tws1cxF5vDhOSzG+WGN5ryoIgK8CbX3Ro8Q6DjzObFv+/oK/O0pwRTb1jn+p9JY eeVw== 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=MoDfDlaidAPuXBw9rdIhpM30CZohZUs73tZCKrQ+vZw=; b=l8tcxkAo0UwhBHW06+cseLclY7j0SFLhz+tJSHfB365EHsruBbuRHa/lLEnuUzfw2K 1mBEulrdxwvGiKPcb7f/tEAX07jV3cA57vbCUUTOC1wuTfs8ryt6Z9zhsmFtPRqmym85 2uzeJpEmqoMPwO9VtW/oGAoVO65nKBDb01PE3DxtKAESn6Y+cPHgLcxfTMvez8wJWbpG TEr+nlu/nblCmDqbC6FKO/PqbNjp27qkbuo6kH6J2HuGruGyRU4x4huanmQyiHy3SU1U xLdoaAwp1XFSmVQRIQBIZ10gCL4LykDJbkcSX1lkE5YYdbtF9yNHVRYFuePlZOqysgfd ZNVw== X-Gm-Message-State: AHQUAuauzp3OwuS6/w1xWAkibTnxAXfjP1qw9pB/Era5fXAQs0mycJAm MP0Yx16UCMWbI+wUJrb6tLEKpavZa5l7rWObpDNDmBIz X-Google-Smtp-Source: AHgI3Ib+RZQux/Ieo3SPaUtSU3phhUldDC5k0uVSJvaTJpxVa3sh5Quyxdbts5Rwidfz12cLH409zoPdERSptduAbs0= X-Received: by 2002:aca:e690:: with SMTP id d138mr280400oih.109.1550057578368; Wed, 13 Feb 2019 03:32:58 -0800 (PST) MIME-Version: 1.0 References: <1549631126-29067-1-git-send-email-magnus.karlsson@intel.com> <36557463-D23A-432E-AA18-7731F43CEBA6@gmail.com> In-Reply-To: <36557463-D23A-432E-AA18-7731F43CEBA6@gmail.com> From: Magnus Karlsson Date: Wed, 13 Feb 2019 12:32:47 +0100 Message-ID: Subject: Re: [PATCH bpf-next v4 0/2] libbpf: adding AF_XDP support To: Jonathan Lemon Cc: Magnus Karlsson , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , ast@kernel.org, Daniel Borkmann , Network Development , Jakub Kicinski , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Zhang, Qi Z" , Jesper Dangaard Brouer , xiaolong.ye@intel.com Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Feb 11, 2019 at 9:44 PM Jonathan Lemon wrote: > > On 8 Feb 2019, at 5:05, Magnus Karlsson wrote: > > > This patch proposes to add AF_XDP support to libbpf. The main reason > > for this is to facilitate writing applications that use AF_XDP by > > offering higher-level APIs that hide many of the details of the AF_XDP > > uapi. This is in the same vein as libbpf facilitates XDP adoption by > > offering easy-to-use higher level interfaces of XDP > > functionality. Hopefully this will facilitate adoption of AF_XDP, make > > applications using it simpler and smaller, and finally also make it > > possible for applications to benefit from optimizations in the AF_XDP > > user space access code. Previously, people just copied and pasted the > > code from the sample application into their application, which is not > > desirable. > > I like the idea of encapsulating the boilerplate logic in a library. > > I do think there is an important missing piece though - there should be > some code which queries the netdev for how many queues are attached, and > create the appropriate number of umem/AF_XDP sockets. > > I ran into this issue when testing the current AF_XDP code - on my test > boxes, the mlx5 card has 55 channels (aka queues), so when the test program > binds only to channel 0, nothing works as expected, since not all traffic > is being intercepted. While obvious in hindsight, this took a while to > track down. Yes, agreed. You are not the first one to stumble upon this problem :-). Let me think a little bit on how to solve this in a good way. We need this to be simple and intuitive, as you say. /Magnus > -- > Jonathan