On Wed, May 13, 2020 at 1:00 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > In Cilium we've recently switched to make use of bpf_jiffies64() for > parts of our tc and XDP datapath since bpf_ktime_get_ns() is more > expensive and high-precision is not needed for our timeouts we have > anyway. Our agent has a probe manager which picks up the json of > bpftool's feature probe and we also use the macro output in our C > programs e.g. to have workarounds when helpers are not available on > older kernels. > > Extend the kernel config info dump to also include the kernel's > CONFIG_HZ, and rework the probe_kernel_image_config() for allowing a > macro dump such that CONFIG_HZ can be propagated to BPF C code as a > simple define if available via config. Latter allows to have _compile- > time_ resolution of jiffies <-> sec conversion in our code since all > are propagated as known constants. > > Given we cannot generally assume availability of kconfig everywhere, > we also have a kernel hz probe [0] as a fallback. Potentially, bpftool > could have an integrated probe fallback as well, although to derive it, > we might need to place it under 'bpftool feature probe full' or similar > given it would slow down the probing process overall. Yet 'full' doesn't > fit either for us since we don't want to pollute the kernel log with > warning messages from bpf_probe_write_user() and bpf_trace_printk() on > agent startup; I've left it out for the time being. > > [0] https://github.com/cilium/cilium/blob/master/bpf/cilium-probe-kernel-hz.c > > Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Cc: Martin KaFai Lau <kafai@xxxxxx> > --- libbpf supports kconfig values, so don't have to even probe for that, it will just appear as a constant global variable: extern unsigned long CONFIG_HZ __kconfig; But I assume you want this for iproute2 case, which doesn't support this, right? We really should try to make iproute2 just use libbpf as a loader with all the libbpf features available. I think all (at least all major ones) features needed are already there in libbpf, iproute2 would just need to implement custom support for old-style map definitions and maybe something else, not sure. I wonder if any of iproute2/BPF users willing to spend some effort on this? > tools/bpf/bpftool/feature.c | 120 ++++++++++++++++++++---------------- > 1 file changed, 67 insertions(+), 53 deletions(-) > [...]
