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:
signature.asc
Description: PGP signature
