On Thu, 14 Nov 2019 at 11:19, Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: > > On 14/11/2019 06:29, Björn Töpel wrote: [...] > > 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. > Yup, correct! > > 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. > Again, thanks for the pointers. PeterZ is (hopefully) still working on the static_call stuff [3]. The static_call_inline would be a good fit here, and maybe even using static_call as a patchpad/dispatcher like you did is a better route. I will checkout Nadav's work! Björn [3] https://lore.kernel.org/lkml/20191007090225.44108711.6@xxxxxxxxxxxxx/#r > -Ed > > [2] https://lkml.org/lkml/2018/12/31/19
