On Fri, 15 Dec 2023 14:49:56 +0900 Akihiko Odaki akihiko.odaki@daynix.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.