On 08/07/2022, Andrii Nakryiko wrote:
On Thu, Jul 7, 2022 at 11:04 PM Jon Doron <arilou@xxxxxxxxx> wrote:
From: Jon Doron <jond@xxxxxx>
Add support for writing a custom event reader, by exposing the ring
buffer state, and allowing to set it's tail.
Few simple examples where this type of needed:
1. perf_event_read_simple is allocating using malloc, perhaps you want
to handle the wrap-around in some other way.
2. Since perf buf is per-cpu then the order of the events is not
guarnteed, for example:
Given 3 events where each event has a timestamp t0 < t1 < t2,
and the events are spread on more than 1 CPU, then we can end
up with the following state in the ring buf:
CPU[0] => [t0, t2]
CPU[1] => [t1]
When you consume the events from CPU[0], you could know there is
a t1 missing, (assuming there are no drops, and your event data
contains a sequential index).
So now one can simply do the following, for CPU[0], you can store
the address of t0 and t2 in an array (without moving the tail, so
there data is not perished) then move on the CPU[1] and set the
address of t1 in the same array.
So you end up with something like:
void **arr[] = [&t0, &t1, &t2], now you can consume it orderely
and move the tails as you process in order.
3. Assuming there are multiple CPUs and we want to start draining the
messages from them, then we can "pick" with which one to start with
according to the remaining free space in the ring buffer.
All the above use cases are sufficiently advanced that you as such an
advanced user should be able to write your own perfbuf consumer code.
There isn't a lot of code to set everything up, but then you get full
control over all the details.
I don't see this API as a generally useful, it feels way too low-level
and special for inclusion in libbpf.
Hi Andrii,
I understand, but I was still hoping you will be willing to expose this
API.
libbpf has very simple and nice binding to Rust and other languages,
implementing one of those use cases in the bindings can make things much
simpler than using some libc or syscall APIs, instead of enjoying all
the simplicity that you get for free in libbpf.
Hope you will be willing to reconsider :)
Have a nice weekend,
-- Jon.
Signed-off-by: Jon Doron <jond@xxxxxx>
---
tools/lib/bpf/libbpf.c | 40 ++++++++++++++++++++++++++++++++++++++++
tools/lib/bpf/libbpf.h | 25 +++++++++++++++++++++++++
tools/lib/bpf/libbpf.map | 2 ++
3 files changed, 67 insertions(+)
[...]
