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.
