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 10C9B43DEB; Wed, 3 Apr 2024 13:50:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9B88C402CE; Wed, 3 Apr 2024 13:50:38 +0200 (CEST) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by mails.dpdk.org (Postfix) with ESMTP id 0BF2D4025C for ; Wed, 3 Apr 2024 13:50:37 +0200 (CEST) Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-41624ebc51aso2367585e9.1 for ; Wed, 03 Apr 2024 04:50:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712145036; x=1712749836; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ODX6QdG9GwEXlN8R1/MDzP2QJle3+QJyfDPeXpHv5Mo=; b=cuEGX4Ob28hn53l/EDxqszwtZSW9srTjUyeTBaLpVDldaGGzjkZBjYdrd3Ey/rXUv3 4GispIU2za5Qteke67FRwMuPJjzSqxN5xvKi8cIybRRXbpRHhPDP2bN26JfFoYmXr6nj v7WKgNBXYHr+sQHyqfTy0edCl1+KbX0OmuqHgY5WLQMhX4linEy7pqjq50wUhPjBddH/ mpctlWno11gTd4CI4ft79zzreyewGojDiM5uNHsZt/7yU9Fp4YwYXTphWgatFQ7XmNkf C1Z24REZ15bR/j3ZOOih+DJ8vSDKizzieMsxogjxZj0dAGhIfsvCTa+a96joTAcjox8z pH6Q== X-Forwarded-Encrypted: i=1; AJvYcCXEyWsL+SqlH16vGjhuF9NW4a9PFrW2q7SWFMb164Z5fk3gv6Aly/dV0Ibx34kqLsNddXdpCWD0Ejcu2Co= X-Gm-Message-State: AOJu0Ywn/V3jM+ryUKWsFKk/JAb+2J4Kt1bVn3Wq2It0XwsuuiNoFUH2 xEII9+Q7TkUziAwJ+T2HsRNNL/JiQt4Ugyrb4UZPXAFnn3dNmMqLi0yQa9ZEwO0= X-Google-Smtp-Source: AGHT+IE7Oh0rtG/neJjMVvcEveAhhPVy+35TIn6+MQsKwUYejbvin8b56rhS5h+pGRoLkcjQgIF/Zg== X-Received: by 2002:a7b:c34d:0:b0:416:1c9f:3a3f with SMTP id l13-20020a7bc34d000000b004161c9f3a3fmr3117394wmj.9.1712145036347; Wed, 03 Apr 2024 04:50:36 -0700 (PDT) Received: from localhost ([137.220.120.171]) by smtp.gmail.com with ESMTPSA id o10-20020a05600c510a00b004148a5e3188sm24550179wms.25.2024.04.03.04.50.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 04:50:35 -0700 (PDT) Message-ID: <8794e9c209bc8b3888ef19452b1cfd3d3c48b9b3.camel@debian.org> Subject: Re: [PATCH v5 7/8] net/tap: use libbpf to load new BPF program From: Luca Boccassi To: Stephen Hemminger , dev@dpdk.org Date: Wed, 03 Apr 2024 12:50:35 +0100 In-Reply-To: <20240402171751.138324-8-stephen@networkplumber.org> References: <20240130034925.44869-1-stephen@networkplumber.org> <20240402171751.138324-1-stephen@networkplumber.org> <20240402171751.138324-8-stephen@networkplumber.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 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 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. >=20 > 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. >=20 > The new BPF program only needs a single action. > No need for action and re-classification step. >=20 > It alsow fixes the missing bits from the original. > - supports setting RSS key per flow > - level of hash can be L3 or L3/L4. >=20 > 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(-) >=20 > 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 @@ > =20 > enable_tap_rss =3D false > =20 > +# Loading BPF requires libbpf > libbpf =3D dependency('libbpf', required: false, method: 'pkg-config') > if not libbpf.found() > message('net/tap: no RSS support missing libbpf') > subdir_done() > endif > =20 > +# Making skeleton needs bpftool > # Debian install this in /usr/sbin which is not in $PATH > -bpftool =3D find_program('bpftool', '/usr/sbin/bpftool', required: false= , version: '>=3D 5.6.0') > -if not bpftool.found() > +bpftool_supports_skel =3D false > +bpftool =3D find_program('bpftool', '/usr/sbin/bpftool', required: false= ) > +if bpftool.found() > + # Some Ubuntu has non-functional bpftool > + bpftool_supports_skel =3D run_command(bpftool, 'gen', 'help', > + check:false).returncode() =3D=3D= 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. 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. 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/d917079e7e320aa281fc4= ad6f8073b0814b9cb13 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. --=20 Kind regards, Luca Boccassi