[LSF/MM/BPF TOPIC] Polymorphic Kfuncs

[LSF/MM/BPF TOPIC] Polymorphic Kfuncs

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

Hello,

Kfuncs [0] allow BPF programs to call out to the main kernel. They are
the modern version of BPF helpers, and don't require any UAPI changes.
With sched_ext, we define a variety of kfuncs for many different
purposes.  For example, the scx_bpf_dispatch() [1] kfunc is used to
"dispatch" a task to a dispatch queue. Other kfuncs are used to e.g. get
a cpumask that tracks idle cores.

[0]: https://docs.kernel.org/bpf/kfuncs.html
[1]: https://github.com/sched-ext/sched_ext/blob/6b747e0ee5fca284330d065a0c777d1991290bc4/kernel/sched/ext.c#L3921

One thing that's interesting about scx_bpf_dispatch() is that while the
interface and advertised semantics of the kfunc are the same regardless
of where it's called, the implementation of the kfunc varies depending
on its calling context. If it's called from a certain set of struct_ops
progs, we do something differently than if it's called from another, due
to implementation details of the subsystem.

We can (and already do) enable this behavior by setting a per-cpu
variable that we check in the kfunc implementation to determine where we
were called from, but it would be more ergonomic if we could instead
specify that a different kfunc implementation should be invoked
depending on which prog it was invoked from as part of the core kfunc
interface. Or, in other words, if we supported "polymorphic" kfuncs.

I'd like to go into more details on how this feature would be used, and
of course to also discuss possible designs.

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]