On Fri, Aug 21, 2020 at 10:06 AM Andrii Nakryiko <andriin@xxxxxx> wrote: > > Add a set of APIs to perf_buffer manage to allow applications to integrate > perf buffer polling into existing epoll-based infrastructure. One example is > applications using libevent already and wanting to plug perf_buffer polling, > instead of relying on perf_buffer__poll() and waste an extra thread to do it. > But perf_buffer is still extremely useful to set up and consume perf buffer > rings even for such use cases. > > So to accomodate such new use cases, add three new APIs: > - perf_buffer__buffer_cnt() returns number of per-CPU buffers maintained by > given instance of perf_buffer manager; > - perf_buffer__buffer_fd() returns FD of perf_event corresponding to > a specified per-CPU buffer; this FD is then polled independently; > - perf_buffer__consume_buffer() consumes data from single per-CPU buffer, > identified by its slot index. > > To support a simpler, but less efficient, way to integrate perf_buffer into > external polling logic, also expose underlying epoll FD through > perf_buffer__epoll_fd() API. It will need to be followed by > perf_buffer__poll(), wasting extra syscall, or perf_buffer__consume(), wasting > CPU to iterate buffers with no data. But could be simpler and more convenient > for some cases. > > These APIs allow for great flexiblity, but do not sacrifice general usability > of perf_buffer. > > Also exercise and check new APIs in perf_buffer selftest. > > Reviewed-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > Signed-off-by: Andrii Nakryiko <andriin@xxxxxx> Applied. Thanks