Björn Töpel <bjorn.topel@xxxxxxxxx> writes: > Overview > ======== > > This is the 4th iteration of the series that introduces the BPF > dispatcher, which is a mechanism to avoid indirect calls. > > The BPF dispatcher is a multi-way branch code generator, targeted for > BPF programs. E.g. when an XDP program is executed via the > bpf_prog_run_xdp(), it is invoked via an indirect call. With > retpolines enabled, the indirect call has a substantial performance > impact. The dispatcher is a mechanism that transform indirect calls to > direct calls, and therefore avoids the retpoline. The dispatcher is > generated using the BPF JIT, and relies on text poking provided by > bpf_arch_text_poke(). > > The dispatcher hijacks a trampoline function it via the __fentry__ nop > of the trampoline. One dispatcher instance currently supports up to 48 > dispatch points. This can be extended in the future. > > In this series, only one dispatcher instance is supported, and the > only user is XDP. The dispatcher is updated when an XDP program is > attached/detached to/from a netdev. An alternative to this could have > been to update the dispatcher at program load point, but as there are > usually more XDP programs loaded than attached, so the latter was > picked. I like the new version where it's integrated into bpf_prog_run_xdp(); nice! :) > The XDP dispatcher is always enabled, if available, because it helps > even when retpolines are disabled. Please refer to the "Performance" > section below. Looking at those numbers, I think I would moderate "helps" to "doesn't hurt" - a difference of less than 1ns is basically in the noise. You mentioned in the earlier version that this would impact the time it takes to attach an XDP program. Got any numbers for this? -Toke
