Messages in this thread | | | Date | Wed, 22 Nov 2023 14:36:32 +0900 | Subject | Re: [RFC PATCH v2 1/7] bpf: Introduce BPF_PROG_TYPE_VNET_HASH | From | Akihiko Odaki <> |
| |
On 2023/11/22 14:25, Song Liu wrote: > On Mon, Nov 20, 2023 at 12:05 AM Akihiko Odaki <akihiko.odaki@daynix.com> wrote: >> >> On 2023/11/20 6:02, Song Liu wrote: > [...] >>>> 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. >>> >>> TBH, I don't think stability should be a concern for kfuncs used by QEMU. >>> Many core BPF APIs are now implemented as kfuncs: bpf_dynptr_*, >>> bpf_rcu_*, etc. As long as there are valid use cases,these kfuncs will >>> be supported. >> >> Documentation/bpf/kfuncs.rst still says: >> > kfuncs provide a kernel <-> kernel API, and thus are not bound by any >> > of the strict stability restrictions associated with kernel <-> user >> > UAPIs. >> >> Is it possible to change the statement like as follows: >> "Most kfuncs provide a kernel <-> kernel API, and thus are not bound by >> any of the strict stability restrictions associated with kernel <-> user >> UAPIs. kfuncs that have same stability restrictions associated with >> UAPIs are exceptional, and must be carefully reviewed by subsystem (and >> BPF?) maintainers as any other UAPIs are." > > I am afraid this is against the intention to not guarantee UAPI-level stability > for kfuncs.
Is it possible to ensure that a QEMU binary with the eBPF program included works on different kernel versions without UAPI-level stability then? Otherwise, I think we need to think of the minimal UAPI addition that exposes the feature I propose, and the two options I presented first are the candidates of such: the stable BPF change or tuntap interface change.
Regards, Akihiko Odaki
| |