eunomia-bpf / bpftime

Userspace eBPF runtime for fast Uprobe & Syscall hook & Extensions with LLVM JIT
https://eunomia.dev/bpftime/
MIT License
693 stars 68 forks source link

attach: fix the performance issue of the new attach implementation #238

Closed Officeyutong closed 4 months ago

Officeyutong commented 4 months ago

Closes #223

This PR allows frida_attach_entry accepting ebpf-arguments-like callbacks, in this way we could avoid an extra callback layer that translates ebpf arguments from original arguments.

Benchmark result of the current commit

image

Benchmark result of the commit prior to the new attach implementation

image

According to the benchmark, the new attach implementation has the same performance as the previous one

yunwei37 commented 4 months ago

Can you introduce how this PR works? It seems like a large PR.

Officeyutong commented 4 months ago

Can you introduce how this PR works? It seems like a large PR.

Allowing frida_attach_entry to store a callback function with signature int(void memory, size_t memory_size, uint64_t return_value). This signature is intended for calling ebpf programs. When the hook is triggered, and the mentioned callback is provided, the corresponding function would be directly triggered.

In the previous design, frida_attach_entry only accept callback with signature void(const pt_regs&). If user want to call a ebpf program with the unified registering interface, a intermediate layer that accepts pt_regs as argument and call the ebpf callback is needed.

So the new design reduces one intermediate callback layer, so the calling latency could be reduced.

Why doesn't frida_attach_entry stores bpftime_prog to call ebpf program? Currently attach parts doesn't depend on any API in runtime, so we can't use bpftime_prog.

yunwei37 commented 4 months ago

Can we make attach part depends on the runtime API? Will that be simple?

Officeyutong commented 4 months ago

Can we make attach part depends on the runtime API? Will that be simple?

runtime has no need to depend on attach (except base_attach_impl), attach also has no need to depend on runtime.

They both depend on base_attach_impl. Attach impls should be registered at runtime, and attach_manager (current bpf_attach_ctx) should be responsible for managing registered attach impls. These procedure has no performance degradation. Attach callbacks are std::function which are directly provided by attach_manager. Abstraction is only needed for a unified attach impl interface