Re: [RFC PATCH v2 1/7] bpf: Introduce BPF_PROG_TYPE_VNET_HASH

[Akihiko Odaki]

On 2023/11/19 1:08, Song Liu wrote:
> Hi,
>
> A few rookie questions below.

Thanks for questions.

> On Sat, Nov 18, 2023 at 2:39 AM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote:
> > On 2023/10/18 4:19, Akihiko Odaki wrote:
> > > On 2023/10/18 4:03, Alexei Starovoitov wrote:
> [...]
> > > I would also appreciate if you have some documentation or link to
> > > relevant discussions on the mailing list. That will avoid having same
> > > discussion you may already have done in the past.
> >
> > Hi,
> >
> > The discussion has been stuck for a month, but I'd still like to
> > continue figuring out the way best for the whole kernel to implement
> > this feature. I summarize the current situation and question that needs
> > to be answered before push this forward:
> >
> > The goal of this RFC is to allow to report hash values calculated with
> > eBPF steering program. It's essentially just to report 4 bytes from the
> > kernel to the userspace.
>
> AFAICT, the proposed design is to have BPF generate some data
> (namely hash, but could be anything afaict) and consume it from
> user space. Instead of updating __sk_buff, can we have the user
> space to fetch the data/hash from a bpf map? If this is an option,
> I guess we can implement the same feature with BPF tracing
> programs?

Unfortunately no. The communication with the userspace can be done with 
two different means:
- usual socket read/write
- vhost for direct interaction with a KVM guest

The BPF map may be a valid option for socket read/write, but it is not 
for vhost. In-kernel vhost may fetch hash from the BPF map, but I guess 
it's not a standard way to have an interaction between the kernel code 
and a BPF program.

> > Unfortunately, however, it is not acceptable for the BPF subsystem
> > because the "stable" BPF is completely fixed these days. The
> > "unstable/kfunc" BPF is an alternative, but the eBPF program will be
> > shipped with a portable userspace program (QEMU)[1] so the lack of
> > interface stability is not tolerable.
>
> bpf kfuncs are as stable as exported symbols. Is exported symbols
> like stability enough for the use case? (I would assume yes.)
>
> > Another option is to hardcode the algorithm that was conventionally
> > implemented with eBPF steering program in the kernel[2]. It is possible
> > because the algorithm strictly follows the virtio-net specification[3].
> > However, there are proposals to add different algorithms to the
> > specification[4], and hardcoding the algorithm to the kernel will
> > require to add more UAPIs and code each time such a specification change
> > happens, which is not good for tuntap.
>
> The requirement looks similar to hid-bpf. Could you explain why that
> model is not enough? HID also requires some stability AFAICT.

I have little knowledge with hid-bpf, but I assume it is more like a 
"safe" kernel module; in my understanding, it affects the system state 
and is intended to be loaded with some kind of a system daemon. It is 
fine to have the same lifecycle with the kernel for such a BPF program; 
whenever the kernel is updated, the distributor can recompile the BPF 
program with the new kernel headers and ship it along with the kernel 
just as like a kernel module.

In contrast, our intended use case is more like a normal application. 
So, for example, a user may download a container and run QEMU (including 
the BPF program) installed in the container. As such, it is nice if the 
ABI is stable across kernel releases, but it is not guaranteed for 
kfuncs. Such a use case is already covered with the eBPF steering 
program so I want to maintain it if possible.

Regards,
Akihiko Odaki