On Thu, Oct 24, 2024 at 1:51 PM Vadim Fedorenko <vadfed@xxxxxxxx> wrote: > > New kfunc to return ARCH-specific timecounter. For x86 BPF JIT converts > it into rdtsc ordered call. Other architectures will get JIT > implementation too if supported. The fallback is to > __arch_get_hw_counter(). > > Signed-off-by: Vadim Fedorenko <vadfed@xxxxxxxx> > --- > v1 -> v2: > * Fix incorrect function return value type to u64 > * Introduce bpf_jit_inlines_kfunc_call() and use it in > mark_fastcall_pattern_for_call() to avoid clobbering in case of > running programs with no JIT (Eduard) > * Avoid rewriting instruction and check function pointer directly > in JIT (Alexei) > * Change includes to fix compile issues on non x86 architectures > --- > arch/x86/net/bpf_jit_comp.c | 30 ++++++++++++++++++++++++++++++ > arch/x86/net/bpf_jit_comp32.c | 16 ++++++++++++++++ > include/linux/filter.h | 1 + > kernel/bpf/core.c | 11 +++++++++++ > kernel/bpf/helpers.c | 7 +++++++ > kernel/bpf/verifier.c | 4 +++- > 6 files changed, 68 insertions(+), 1 deletion(-) > [...] > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > index 5c3fdb29c1b1..f7bf3debbcc4 100644 > --- a/kernel/bpf/helpers.c > +++ b/kernel/bpf/helpers.c > @@ -23,6 +23,7 @@ > #include <linux/btf_ids.h> > #include <linux/bpf_mem_alloc.h> > #include <linux/kasan.h> > +#include <vdso/datapage.h> > > #include "../../lib/kstrtox.h" > > @@ -3023,6 +3024,11 @@ __bpf_kfunc int bpf_copy_from_user_str(void *dst, u32 dst__sz, const void __user > return ret + 1; > } > > +__bpf_kfunc u64 bpf_get_hw_counter(void) Hm... so the main idea behind this helper is to measure latency (i.e., time), right? So, first of all, the name itself doesn't make it clear that this is **time stamp** counter, so maybe let's mention "timestamp" somehow? But then also, if I understand correctly, it will return the number of cycles, right? And users would need to somehow convert that to nanoseconds to make it useful. Is it trivial to do that from the BPF side? If not, can we specify this helper to return nanoseconds instead of cycles, maybe? It would be great if selftest demonstratef the intended use case of measuring some kernel function latency (or BPF helper latency, doesn't matter much). [...]
