Date: Sat, 16 Dec 2023 17:15:39 +0900
From: Akihiko Odaki <akihiko.odaki@...nix.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
 Alexei Starovoitov <alexei.starovoitov@...il.com>,
 Jason Wang <jasowang@...hat.com>, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>,
 Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Jonathan Corbet <corbet@....net>,
 Willem de Bruijn <willemdebruijn.kernel@...il.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 "Michael S. Tsirkin" <mst@...hat.com>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>, Mykola Lysenko <mykolal@...com>,
 Shuah Khan <shuah@...nel.org>, Yuri Benditovich
 <yuri.benditovich@...nix.com>, Andrew Melnychenko <andrew@...nix.com>,
 Benjamin Tissoires <bentiss@...nel.org>, bpf <bpf@...r.kernel.org>,
 "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, kvm@...r.kernel.org,
 LKML <linux-kernel@...r.kernel.org>,
 virtualization@...ts.linux-foundation.org,
 "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>,
 Network Development <netdev@...r.kernel.org>
Subject: Re: Should I add BPF kfuncs for userspace apps? And how?

On 2023/12/16 1:36, Stephen Hemminger wrote:
> On Fri, 15 Dec 2023 14:49:56 +0900
> Akihiko Odaki <akihiko.odaki@...nix.com> wrote:
> 
>>>> It is exactly what BPF_PROG_TYPE_SOCKET_FILTER does, but it lacks a
>>>> mechanism to report hash values so I need to extend it or invent a new
>>>> method. Extending BPF_PROG_TYPE_SOCKET_FILTER is not a way forward since
>>>> CO-RE is superior to the context rewrite it relies on. But apparently
>>>> adopting kfuncs and CO-RE also means to lose the "we don't break user
>>>> space" contract although I have no intention to expose kernel internals
>>>> to the eBPF program.
>>>
>>> An example is how one part of DPDK recomputes RSS over TAP.
>>>
>>> https://git.dpdk.org/dpdk/tree/drivers/net/tap/bpf/tap_bpf_program.c
>>>
>>> This feature is likely to be removed, because it is not actively used
>>> and the changes in BPF program loading broke it on current kernel
>>> releases.  Which brings up the point that since the kernel does
>>> not have stable API/ABI for BPF program infrastructure, I would
>>> avoid it for projects that don't want to deal with that.
>>
>> It's unfortunate to hear that, but thanks for the information.
>> I'll consider more about the option not using BPF (plain ioctl and
>> in-kernel implementation).
> 
> With libbpf, things are much better. It is just that projects like
> DPDK have to support wide range of kernels including older versions of RHEL.

I have checked DPDK documentation. It says it supports the oldest LTS 
kernel:
https://doc.dpdk.org/guides/linux_gsg/sys_reqs.html#system-software

My use case is QEMU, which has much more relaxed compatibility 
requirement that refers to recent distribution versions instead of LTS 
kernels:
https://qemu.readthedocs.io/en/v8.1.0/about/build-platforms.html

That said, I'm not really concerned about the case running QEMU on older 
kernels. QEMU developers can just pay extra efforts to support those old 
kernels if necessary.

The more concerning scenario is that a newer kernel breaks compatibility 
with older QEMU versions; such a scenario has not been considered before 
AFAIK.

QEMU already uses libbpf to load a BPF_PROG_TYPE_SOCKET_FILTER program.

Powered by blists - more mailing lists