Re: [RFC bpf-next 00/11] bpf: inlinable kfuncs for BPF

[Eduard Zingerman <eddyz87@gmail.com>]

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.

> 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.

Thanks,
Eduard