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 287FAC282CE for ; Mon, 11 Feb 2019 19:48:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E757D21B25 for ; Mon, 11 Feb 2019 19:48:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hB69OoLP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730699AbfBKTsj (ORCPT ); Mon, 11 Feb 2019 14:48:39 -0500 Received: from mail-pf1-f193.google.com ([209.85.210.193]:39323 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727639AbfBKTsj (ORCPT ); Mon, 11 Feb 2019 14:48:39 -0500 Received: by mail-pf1-f193.google.com with SMTP id f132so49122pfa.6 for ; Mon, 11 Feb 2019 11:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=0o3Z2v5BLbu6qJ+JTDasEs5y6M47THpL/QHARl/CJNw=; b=hB69OoLPYycUZ97/aXveqBgsIvg5mbmTqVb/BWV4oiPMBTwCW6r+YjsNYaw21utudq CXhqZBNXwfmy7UVitskgU82s4P3sFDxJn9ZumEJKNzgMjS8IECsVcrj4QcTo7I0wDpJS 4O95Mk2mti+WGmujsLlVERg6Lagl8Zc3ku7vQnLAJbijxfmWm4oQdZiH/Y0F28y2ACx0 1q4LcJBc4C9jth51bovRxOsIXqU11HCbpmXAsu9g+6tAkvEcHjwqJtcBRT5QLbpMv1Hf lN3S/faCxoyoLqWfhuHgEKi2vjY3TIu6Wu7VtJYXzM/FlRy6aIWLkOxf0z8EAMM9sbaa qYnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=0o3Z2v5BLbu6qJ+JTDasEs5y6M47THpL/QHARl/CJNw=; b=qAftxJeSRMN/He8/fZLnGjgCPwLKtncTX7NXcLIypCHnClD8scq8gDRCSB0qrYXwyI ZHIRWWv6bulmaeSEjHv4hXfe7TW5qh+iEm9uvoyAAqOp9Sd6ligs6bMWiq4MHtdKh3Be 788JJKT0SNccC4sOtdB+tn9iRPW9WM8yaIY02jDxdqrr4vwEuJE/2yV2aHiw7zMegAzW qSzhLmY0ZN2CURAK8l0/SWlcqxSrckWfnXPzPDIvfWdOSY97XpFlcMRmJuQCdxsdH51c NwTVhN9ej00wj3gtWLRyvdq5A7/knGTuBtTrQIB8zI9w8feIcLo2/n1Sdw1PA9c119I7 SnHw== X-Gm-Message-State: AHQUAuZta/jkb/IHGB3GLQ5CWkNn2+yZNCN1f45gNJSCsOdR2gKmYtEm kkvGY83JYFE99b8LqAizLTg= X-Google-Smtp-Source: AHgI3IbK1t6F6jK113B9ifD4EiKdhSWC4UOQs/F6woJAIWBJ/8G+OaNHnbf3jG7WmBC1a8kqvmXDlw== X-Received: by 2002:a63:160d:: with SMTP id w13mr9414268pgl.85.1549914518396; Mon, 11 Feb 2019 11:48:38 -0800 (PST) Received: from [172.26.114.4] ([2620:10d:c090:180::1:9862]) by smtp.gmail.com with ESMTPSA id y19sm11602354pfm.181.2019.02.11.11.48.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 11:48:36 -0800 (PST) From: "Jonathan Lemon" To: "Magnus Karlsson" Cc: bjorn.topel@intel.com, ast@kernel.org, daniel@iogearbox.net, netdev@vger.kernel.org, jakub.kicinski@netronome.com, bjorn.topel@gmail.com, qi.z.zhang@intel.com, brouer@redhat.com, xiaolong.ye@intel.com Subject: Re: [PATCH bpf-next v4 0/2] libbpf: adding AF_XDP support Date: Mon, 11 Feb 2019 11:48:34 -0800 X-Mailer: MailMate (1.12.4r5594) Message-ID: <36557463-D23A-432E-AA18-7731F43CEBA6@gmail.com> In-Reply-To: <1549631126-29067-1-git-send-email-magnus.karlsson@intel.com> References: <1549631126-29067-1-git-send-email-magnus.karlsson@intel.com> MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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. -- Jonathan