Skip to content

Commit fde6ded

Browse files
anakryikoAlexei Starovoitov
authored and
Alexei Starovoitov
committed
docs/bpf: Fix ringbuf documentation
Remove link to litmus tests that didn't make it to upstream. Fix ringbuf benchmark link. I wasn't able to test this with `make htmldocs`, unfortunately, because of Sphinx dependencies. But bench_ringbufs.c path is certainly correct now. Fixes: 97abb2b ("docs/bpf: Add BPF ring buffer design notes") Reported-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
1 parent 746f534 commit fde6ded

File tree

1 file changed

+1
-4
lines changed

1 file changed

+1
-4
lines changed

Documentation/bpf/ringbuf.rst

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -182,9 +182,6 @@ in the order of reservations, but only after all previous records where
182182
already committed. It is thus possible for slow producers to temporarily hold
183183
off submitted records, that were reserved later.
184184

185-
Reservation/commit/consumer protocol is verified by litmus tests in
186-
Documentation/litmus_tests/bpf-rb/_.
187-
188185
One interesting implementation bit, that significantly simplifies (and thus
189186
speeds up as well) implementation of both producers and consumers is how data
190187
area is mapped twice contiguously back-to-back in the virtual memory. This
@@ -200,7 +197,7 @@ a self-pacing notifications of new data being availability.
200197
being available after commit only if consumer has already caught up right up to
201198
the record being committed. If not, consumer still has to catch up and thus
202199
will see new data anyways without needing an extra poll notification.
203-
Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbuf.c_) show that
200+
Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbufs.c_) show that
204201
this allows to achieve a very high throughput without having to resort to
205202
tricks like "notify only every Nth sample", which are necessary with perf
206203
buffer. For extreme cases, when BPF program wants more manual control of

0 commit comments

Comments
 (0)