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