The future of bpf_dispatcher

The future of bpf_dispatcher

[Björn Töpel]

In the recent weeks there have been various issues [1] [2] (warnings, ftrace
breakage) related to the bpf_dispatcher. The dispatcher was introduced
to reduce the cost of indirect calls for the XDP realm, and during the
whole retpoline timeline it was doing its job pretty good.

However, it's a somewhat odd animal in the kernel, and very x86
specific.

Is the bpf_dispatcher still relevant? If yes, can it be replaced by a
more generic functionality (e.g. static_calls)?


Thoughts?
Björn


[1] https://lore.kernel.org/bpf/20220923211837.3044723-1-song@kernel.org/
[2] https://lore.kernel.org/bpf/20220903131154.420467-1-jolsa@kernel.org/

Re: The future of bpf_dispatcher

[Toke Høiland-Jørgensen]

Björn Töpel <bjorn.topel@gmail.com> writes:

> In the recent weeks there have been various issues [1] [2] (warnings, ftrace
> breakage) related to the bpf_dispatcher. The dispatcher was introduced
> to reduce the cost of indirect calls for the XDP realm, and during the
> whole retpoline timeline it was doing its job pretty good.
>
> However, it's a somewhat odd animal in the kernel, and very x86
> specific.
>
> Is the bpf_dispatcher still relevant? If yes, can it be replaced by a
> more generic functionality (e.g. static_calls)?

During Daniel's talk at LPC (about TC attachment) he mentioned that he
was planning to support multiple programs by iterating through an array
and doing an indirect call into each. I asked if we could avoid the
indirect calls by generating a bpf_dispatcher-style trampoline instead
(and further down the line extend this to XDP as well, like what libxdp
is doing).

No one seemed to complain loudly about this idea in the session; so I'm
hoping that the future of bpf_dispatcher is that we can generalise it so
it can be used for both TC and XDP, and also support chaining of
multiple programs on a single hook.

I don't have any opinion on how the low-level plumbing for this should
work, though; if changing it to re-use other kernel functionality like
static_calls makes sense, that's fine with me...

WDYT, sounds feasible? :)

-Toke