Eduard Zingerman <eddyz87@xxxxxxxxx> writes: > On Fri, 2024-11-08 at 21:41 +0100, Toke Høiland-Jørgensen wrote: > > [...] > > Hi Toke, > >> Back when we settled on the kfunc approach to reading metadata, we were >> discussing this overhead, obviously, and whether we should do the >> bespoke BPF assembly type inlining that we currently do for map lookups >> and that sort of thing. We were told that the "right" way to do the >> inlining is something along the lines of what you are proposing here, so >> I would very much encourage you to continue working on this! >> >> One complication for the XDP kfuncs is that the kfunc that the BPF >> program calls is actually a stub function in the kernel core; at >> verification time, the actual function call is replaced with one from >> the network driver (see bpf_dev_bound_resolve_kfunc()). So somehow >> supporting this (with kfuncs defined in drivers, i.e., in modules) would >> be needed for the XDP use case. > > Thank you for the pointer to bpf_dev_bound_resolve_kfunc(). > Looking at specialize_kfunc(), I will have to extend the interface for > selecting inlinable function body. The inlinable kfuncs already could > be defined in modules, so this should be a relatively small adjustment. Awesome! >> Happy to help with benchmarking for the XDP use case when/if this can be >> supported, of course! :) >> >> (+Jesper, who I'm sure will be happy to help as well) > > Thank you, help with benchmarking is most welcome. > Very interested in real-world benchmarks, as I'm not fully sold on > this feature, it adds significant layer of complexity to the verifier. > I'll reach to you and Jesper after adding support for inlining of XDP > metadata kfuncs. Sounds good, thanks! -Toke
