From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F022643DED; Wed, 3 Apr 2024 16:53:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC1814025C; Wed, 3 Apr 2024 16:53:57 +0200 (CEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by mails.dpdk.org (Postfix) with ESMTP id 557CE40144 for ; Wed, 3 Apr 2024 16:53:56 +0200 (CEST) Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-6e6bee809b8so6094783b3a.1 for ; Wed, 03 Apr 2024 07:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1712156035; x=1712760835; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=lIrU9Vuf5+Od6AKJi64OFy8h0pndt3cUYo2Ho0sBq/w=; b=zCOoe9WcwiU42C++tR/TvTu4+IIGVLE9qdxlgR9U3x62H5FUUjC2y+mAo1oRYHPNdZ kMdBHOjBABajQDT1yA090e6VsP+kd8ddsbt8CDhdTUy4H4trdk1cPmT+ck+FFfCdrgYT sBJcIDXc8m7p8GDxPJxp7sEUFH/bOC5Ly9zHInj5zHZqtKCBFeo9yrahNd/4mN27wp38 DVLuizLkJAacVnq8SurDUgmn/3v6wtBK4cFweILpfA88fly9WnQu2Ik43JmChbO8r9E6 yhddsrBunMvU3PRDK5ke81vVD+NiZW3zuF3XWt+eOuA2e1yLOTqEy3nVMA5gzdjudGwQ 37Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712156035; x=1712760835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lIrU9Vuf5+Od6AKJi64OFy8h0pndt3cUYo2Ho0sBq/w=; b=hiPor1JINpRJH0S6doNwODabNDWRvzFVyo3crPyrYAhRCNVGN9DsT4vKVWNH1SM2GM a5UkMMVjhnP2K39InhRhL0AzMNwYBvS55Gimj3Fs53uPapyTBnHKQJDOsiUoKyuLDZ7U O38AbeE6MWDFIRkF8bY/3+TxKodNxrMPd2G6VGl0wVgWV6pYrFAsYIFcuUa0FsrH5Z2T zI3N6OWtMhwilBWcmgX9q7xkYuEnw93z9KmwzCZqWNpyJemV54BA9WArpiWdMaEv6q1U smm7Qua2QUJ54tYQAJcsCEvDN91USuR1hyk2wwuceHb3hZAJe7/MlbU9cfPF4IwvFC3m sxNg== X-Gm-Message-State: AOJu0YxjkSRHpPNQ6lSYB+wd4OVbOpRcmKxlWpTIcApqLwYdx4Kpbd3N 2Z/U7rto92AtxRhUS0TmCR2QvZzuz0E7f/rwPhcs+TIfo/rrYnWuP9JYS9YB3iU= X-Google-Smtp-Source: AGHT+IH0svLP5lfpMXgf6IrrWvpD+QfGRHYYt+RXD6qDr39fvhD4TNvfHJnRwkOfXPy9xVWFBXdgEQ== X-Received: by 2002:a05:6a00:2e27:b0:6ea:8604:cb1e with SMTP id fc39-20020a056a002e2700b006ea8604cb1emr16427751pfb.19.1712156035286; Wed, 03 Apr 2024 07:53:55 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id a17-20020aa78e91000000b006e535bf8da4sm11675803pfr.57.2024.04.03.07.53.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 07:53:55 -0700 (PDT) Date: Wed, 3 Apr 2024 07:53:54 -0700 From: Stephen Hemminger To: Luca Boccassi Cc: dev@dpdk.org Subject: Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program Message-ID: <20240403075354.1d7a71b8@hermes.local> In-Reply-To: <8794e9c209bc8b3888ef19452b1cfd3d3c48b9b3.camel@debian.org> References: <20240130034925.44869-1-stephen@networkplumber.org> <20240402171751.138324-1-stephen@networkplumber.org> <20240402171751.138324-8-stephen@networkplumber.org> <8794e9c209bc8b3888ef19452b1cfd3d3c48b9b3.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, 03 Apr 2024 12:50:35 +0100 Luca Boccassi wrote: > On Tue, 2024-04-02 at 10:12 -0700, Stephen Hemminger wrote: > > There were multiple issues in the RSS queue support in the TAP > > driver. This required extensive rework of the BPF support. > > > > Change the BPF loading to use bpftool to > > create a skeleton header file, and load with libbpf. > > The BPF is always compiled from source so less chance that > > source and instructions diverge. Also resolves issue where > > libbpf and source get out of sync. The program > > is only loaded once, so if multiple rules are created > > only one BPF program is loaded in kernel. > > > > The new BPF program only needs a single action. > > No need for action and re-classification step. > > > > It alsow fixes the missing bits from the original. > > - supports setting RSS key per flow > > - level of hash can be L3 or L3/L4. > > > > Signed-off-by: Stephen Hemminger > > --- > > drivers/net/tap/bpf/meson.build | 14 +- > > drivers/net/tap/meson.build | 29 +-- > > drivers/net/tap/rte_eth_tap.c | 2 + > > drivers/net/tap/rte_eth_tap.h | 9 +- > > drivers/net/tap/tap_flow.c | 410 +++++++------------------------- > > drivers/net/tap/tap_flow.h | 16 +- > > drivers/net/tap/tap_rss.h | 10 +- > > drivers/net/tap/tap_tcmsgs.h | 4 +- > > 8 files changed, 127 insertions(+), 367 deletions(-) > > > > diff --git a/drivers/net/tap/bpf/meson.build b/drivers/net/tap/bpf/meson.build > > index f2c03a19fd..3f3c4e6602 100644 > > --- a/drivers/net/tap/bpf/meson.build > > +++ b/drivers/net/tap/bpf/meson.build > > @@ -3,15 +3,24 @@ > > > > enable_tap_rss = false > > > > +# Loading BPF requires libbpf > > libbpf = dependency('libbpf', required: false, method: 'pkg-config') > > if not libbpf.found() > > message('net/tap: no RSS support missing libbpf') > > subdir_done() > > endif > > > > +# Making skeleton needs bpftool > > # Debian install this in /usr/sbin which is not in $PATH > > -bpftool = find_program('bpftool', '/usr/sbin/bpftool', required: false, version: '>= 5.6.0') > > -if not bpftool.found() > > +bpftool_supports_skel = false > > +bpftool = find_program('bpftool', '/usr/sbin/bpftool', required: false) > > +if bpftool.found() > > + # Some Ubuntu has non-functional bpftool > > + bpftool_supports_skel = run_command(bpftool, 'gen', 'help', > > + check:false).returncode() == 0 > > +endif > > Using bpftool to generate the header at build time is a bit icky, > because it will look at sysfs on the build system, which is from the > running kernel. But a build system's kernel might be some ancient LTS, > and even be a completely different kconfig/build/distro from the actual > runtime one. I wish there was a better way to get bpf compiled to an array to load. The other alternative is to embed the object but then the ickiness of decoding ELF headers ends up in the driver. This method seems to be the BPF way now. > > We have ran in the same problem in systemd recently, and the solution > is to have distros publish the vmlinux.h together with the kernel > image/headers, that way we can rely on the fact that by build-depending > on the right kernel package we get exactly the generated vmlinux.h that > we want. This has already happened in Centos, Debian, Fedora and Arch, > and I am trying to get Ubuntu onboard too. Not sure how much it matters for the TAP BPF bits. Unlike other kernel BPF this program only really depends on layout of skb, and is not using system call hooks. So vmlinux.h is not referenced directly. But if layout of skb changes, then things would break. > The annoying thing is that every distro packages differently, so the > path needs to be configurable with a meson option. > > Feel free to pilfer the systemd meson glue: > > https://github.com/systemd/systemd/pull/26826/commits/d917079e7e320aa281fc4ad6f8073b0814b9cb13 > > It's of course file to go to the runtime kernel if no vmlinux.h is > specified, as a fallback, which is going to be useful for developers > machines. >