On 14/11/2019 06:29, Björn Töpel wrote: > On Wed, 13 Nov 2019 at 22:41, Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: >> On 13/11/2019 20:47, Björn Töpel wrote: >> The first-come-first-served model for dispatcher slots might mean that >> a low-traffic user ends up getting priority while a higher-traffic >> user is stuck with the retpoline fallback. Have you considered using >> a learning mechanism, like in my dynamic call RFC [1] earlier this >> year? (Though I'm sure a better learning mechanism than the one I >> used there could be devised.) > My rationale was that this mechanism would almost exclusively be used > by physical HW NICs using XDP. My hunch was that the number of netdevs > would be ~4, and typically less using XDP, so a more sophisticated > mechanism didn't really make sense IMO. That seems reasonable in most cases, although I can imagine systems with a couple of four-port boards being a thing. I suppose the netdevs are likely to all have the same XDP prog, though, and if I'm reading your code right it seems they'd share a slot in that case. > However, your approach is more > generic and doesn't require any arch specific work. What was the push > back for your work? Mainly that I couldn't demonstrate a performance benefit from the few call sites I annotated, and others working in the area felt that manual annotation wouldn't scale — Nadav Amit had a different approach [2] that used a GCC plugin to apply a dispatcher on an opt-out basis to all the indirect calls in the kernel; the discussion on that got bogged down in interactions between text patching and perf tracing which all went *waaaay* over my head. AFAICT the static_call series I was depending on never got merged, and I'm not sure if anyone's still working on it. -Ed [2] https://lkml.org/lkml/2018/12/31/19
