On Sat, Jul 9, 2022 at 10:43 PM Jon Doron <arilou@xxxxxxxxx> wrote: > > I was referring to the following: > https://github.com/libbpf/libbpf-rs/blob/master/libbpf-rs/src/perf_buffer.rs How does your patch help libbpf-rs? Please don't top post. > Thanks, > -- Jon. > > On Sun, Jul 10, 2022, 08:23 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: >> >> On Fri, Jul 8, 2022 at 7:54 PM Jon Doron <arilou@xxxxxxxxx> wrote: >> > >> > 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 :) >> >> The discussion would have been different if you mentioned that >> motivation in the commit logs. >> Please provide links to "Rust and other languages" code that >> uses this api.
