On 9/20/23 18:28, Andrii Nakryiko wrote:
On Thu, Sep 14, 2023 at 4:12 PM Martin Kelly
<martin.kelly@xxxxxxxxxxxxxxx> wrote:
This patch series adds a new ring__ API to libbpf exposing getters for accessing
the individual ringbuffers inside a struct ring_buffer. This is useful for
polling individually, getting available data, or similar use cases. The API
looks like this, and was roughly proposed by Andrii Nakryiko in another thread:
Getting a ring struct:
struct ring *ring_buffer__ring(struct ring_buffer *rb, unsigned int idx);
Using the ring struct:
unsigned long ring__consumer_pos(const struct ring *r);
unsigned long ring__producer_pos(const struct ring *r);
size_t ring__avail_data_size(const struct ring *r);
size_t ring__size(const struct ring *r);
int ring__map_fd(const struct ring *r);
int ring__consume(struct ring *r);
Martin Kelly (14):
libbpf: refactor cleanup in ring_buffer__add
libbpf: switch rings to array of pointers
libbpf: add ring_buffer__ring
selftests/bpf: add tests for ring_buffer__ring
libbpf: add ring__producer_pos, ring__consumer_pos
selftests/bpf: add tests for ring__*_pos
libbpf: add ring__avail_data_size
selftests/bpf: add tests for ring__avail_data_size
libbpf: add ring__size
selftests/bpf: add tests for ring__size
libbpf: add ring__map_fd
selftests/bpf: add tests for ring__map_fd
libbpf: add ring__consume
selftests/bpf: add tests for ring__consume
tools/lib/bpf/libbpf.h | 68 +++++++++++++++
tools/lib/bpf/libbpf.map | 7 ++
tools/lib/bpf/ringbuf.c | 87 +++++++++++++++----
.../selftests/bpf/prog_tests/ringbuf.c | 38 +++++++-
.../selftests/bpf/prog_tests/ringbuf_multi.c | 16 ++++
5 files changed, 199 insertions(+), 17 deletions(-)
--
2.34.1
Looks mostly good, sorry for taking a while to get to these. I left a
few comments here and there, please address and submit v2. Try to use
consistent "ring buffer manager" and "ring buffer map" to distinguish
them in doc comments. And also please don't add new CHECK() uses to
selftests, we have a whole family of ASSERT_xxx() macros, please use
them.
Thanks, I agree with all the comments and will issue a v2 as soon as I
can. I noticed the ringbuffer vs ringbuffer manager discrepancy but
wasn't sure which phrasing was better, as the API and struct names are
ring_buffer and ring instead of ring_buffer_manager and ring_buffer.
I'll change it up to consistently refer to the parent struct as "ring
buffer manager".
