Commit fde6dedf authored by Andrii Nakryiko's avatar Andrii Nakryiko Committed by Alexei Starovoitov

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: 97abb2b3 ("docs/bpf: Add BPF ring buffer design notes")
Reported-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200910225245.2896991-1-andriin@fb.com
parent 746f534a
...@@ -182,9 +182,6 @@ in the order of reservations, but only after all previous records where ...@@ -182,9 +182,6 @@ in the order of reservations, but only after all previous records where
already committed. It is thus possible for slow producers to temporarily hold already committed. It is thus possible for slow producers to temporarily hold
off submitted records, that were reserved later. off submitted records, that were reserved later.
Reservation/commit/consumer protocol is verified by litmus tests in
Documentation/litmus_tests/bpf-rb/_.
One interesting implementation bit, that significantly simplifies (and thus One interesting implementation bit, that significantly simplifies (and thus
speeds up as well) implementation of both producers and consumers is how data speeds up as well) implementation of both producers and consumers is how data
area is mapped twice contiguously back-to-back in the virtual memory. This 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. ...@@ -200,7 +197,7 @@ a self-pacing notifications of new data being availability.
being available after commit only if consumer has already caught up right up to being available after commit only if consumer has already caught up right up to
the record being committed. If not, consumer still has to catch up and thus the record being committed. If not, consumer still has to catch up and thus
will see new data anyways without needing an extra poll notification. will see new data anyways without needing an extra poll notification.
Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbuf.c_) show that Benchmarks (see tools/testing/selftests/bpf/benchs/bench_ringbufs.c_) show that
this allows to achieve a very high throughput without having to resort to this allows to achieve a very high throughput without having to resort to
tricks like "notify only every Nth sample", which are necessary with perf tricks like "notify only every Nth sample", which are necessary with perf
buffer. For extreme cases, when BPF program wants more manual control of buffer. For extreme cases, when BPF program wants more manual control of
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment