Question about TRACEPOINT benchmarking

[jetlime]

Dear @bobrik, I took a closer look at the benchmark you created for different eBPF attachment types tracing the getpid system call. Thank you for the thorough work, it’s very interesting and well implemented!

I do have a question about the results related to the tracepoint case. In your evaluation of the tracepoint case, you used the tp_btf attachment type:

ebpf_exporter/benchmark/probes/benchmark.bpf.h

Line 20 in dabb53a

#define TRACEPOINT_SEC() SEC("tp_btf/sys_enter")

From what I understand (and confirmed via ebpf.docs.io and bpftool), tp_btf is a TRACING program type, not a TRACEPOINT program.

When I replace the macro to use a tracepoint attachment for getpid:

#define TRACEPOINT_SEC() SEC("tracepoint/syscalls/sys_enter_getpid")

I observe different benchmark results, with tracepoints performing worse than fentry, differing from your results. Also, tp_btf fires on every syscall, not just getpid. Could you share your reasoning for using tp_btf instead of tracepoint/syscalls/sys_enter_getpid to specifically trace the getpid syscall? A tp_btf, raw tracepoint, shall be specified as such in the benchmark results instead of using the term tracepoint.

[bobrik]

From what I understand (and confirmed via ebpf.docs.io and bpftool), tp_btf is a TRACING program type, not a TRACEPOINT program.

It is a tracing program type, but you do attach it to a tracepoint. It's not about the program type, more about what you target.

I observe different benchmark results, with tracepoints performing worse than fentry, differing from your results.

That is exactly the reason to use tp_btf: it is faster and more ergonomic.

Also, tp_btf fires on every syscall, not just getpid.

Yes. Unfurtunately, tp_btf is not available for individual syscall tracepoints. There you have no choice.

The benchmark assumes that you mostly run getpid and there's no background noise. I should've been more clear about it.

We can certainly expand the benchmark to use different attachment types and to add a bit more context around differences. At some point you kind of start to question whether that's something libbpf should provide instead.