* [PATCH bpf] docs/bpf: fix ringbuf documentation
@ 2020-09-10 22:52 Andrii Nakryiko
2020-09-11 3:19 ` Alexei Starovoitov
2020-09-11 6:38 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 3+ messages in thread
From: Andrii Nakryiko @ 2020-09-10 22:52 UTC (permalink / raw)
To: bpf, netdev, ast, daniel
Cc: andrii.nakryiko, kernel-team, Andrii Nakryiko, Mauro Carvalho Chehab
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.
Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fixes: 97abb2b39682 ("docs/bpf: Add BPF ring buffer design notes")
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
---
Documentation/bpf/ringbuf.rst | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/bpf/ringbuf.rst b/Documentation/bpf/ringbuf.rst
index 75f943f0009d..4d4f3bcb1477 100644
--- a/Documentation/bpf/ringbuf.rst
+++ b/Documentation/bpf/ringbuf.rst
@@ -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
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
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
@@ -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
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.
-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
tricks like "notify only every Nth sample", which are necessary with perf
buffer. For extreme cases, when BPF program wants more manual control of
--
2.24.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] docs/bpf: fix ringbuf documentation
2020-09-10 22:52 [PATCH bpf] docs/bpf: fix ringbuf documentation Andrii Nakryiko
@ 2020-09-11 3:19 ` Alexei Starovoitov
2020-09-11 6:38 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 3+ messages in thread
From: Alexei Starovoitov @ 2020-09-11 3:19 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, Network Development, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Kernel Team, Mauro Carvalho Chehab
On Thu, Sep 10, 2020 at 3:53 PM Andrii Nakryiko <andriin@fb.com> wrote:
>
> 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.
>
> Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Fixes: 97abb2b39682 ("docs/bpf: Add BPF ring buffer design notes")
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Applied to bpf tree. Thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH bpf] docs/bpf: fix ringbuf documentation
2020-09-10 22:52 [PATCH bpf] docs/bpf: fix ringbuf documentation Andrii Nakryiko
2020-09-11 3:19 ` Alexei Starovoitov
@ 2020-09-11 6:38 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 3+ messages in thread
From: Mauro Carvalho Chehab @ 2020-09-11 6:38 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, netdev, ast, daniel, andrii.nakryiko, kernel-team, Jonathan Corbet
Hi Andrii,
Em Thu, 10 Sep 2020 15:52:45 -0700
Andrii Nakryiko <andriin@fb.com> escreveu:
> Remove link to litmus tests that didn't make it to upstream. Fix ringbuf
> benchmark link.
That work, thanks!
> I wasn't able to test this with `make htmldocs`, unfortunately, because of
> Sphinx dependencies.
Weird. "make htmldocs" should be calling ./scripts/sphinx-pre-install, which
tells what's needed to install Sphinx:
$ make htmldocs
Documentation/Makefile:30: The 'sphinx-build' command was not found. Make sure you have Sphinx installed and in PATH, or set the SPHINXBUILD make variable to point to the full path of the 'sphinx-build' executable.
Detected OS: Ubuntu 19.10.
Warning: It is recommended at least Sphinx version 1.7.9.
If you want pdf, you need at least 2.4.4.
Note: It is recommended at least Sphinx version 2.4.4 if you need PDF support.
/usr/bin/python3 -m venv sphinx_2.4.4
. sphinx_2.4.4/bin/activate
pip install -r ./Documentation/sphinx/requirements.txt
By default, it recommends installing LaTeX, as this is needed by some
books that use LaTeX markup for formulas (and also to make pdfdocs).
That would require installing lots of things. You can get a lightweight
dependency chain by calling:
./scripts/sphinx-pre-install --no-pdf
Please let me know if you find any troubles with that.
> But bench_ringbufs.c path is certainly correct now.
It still produces this warning for bench_ringbufs.c:
/devel/v4l/docs/Documentation/bpf/ringbuf.rst:194: WARNING: Unknown target name: "bench_ringbufs.c".
That's said, I'm not sure if it is possible to do a cross-reference
like this:
tools/testing/selftests/bpf/benchs/bench_ringbufs.c_
The thing is that bench_ringbufs.c won't be at the doc output
directory (Documentation/output, by default), so Sphinx won't
be able to solve the reference.
Maybe it could still be possible to use that without including
the file at the documentation output dir, but with some extension like:
https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
Such extension creates "external" cross-references to some website.
There were some inconclusive discussions about using it at linux-doc ML,
but nobody so far tested doing it or sent any patches moving toward such
direction.
Another possibility would be to include bench_ringbufs.c inside
the documentation book, using kernel-include::, literalinclude:: or
include:: tags.
Se, for example:
Documentation/kbuild/issues.rst
Documentation/netlabel/draft_ietf.rst
Regards,
Mauro
>
> Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Fixes: 97abb2b39682 ("docs/bpf: Add BPF ring buffer design notes")
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> Documentation/bpf/ringbuf.rst | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/Documentation/bpf/ringbuf.rst b/Documentation/bpf/ringbuf.rst
> index 75f943f0009d..4d4f3bcb1477 100644
> --- a/Documentation/bpf/ringbuf.rst
> +++ b/Documentation/bpf/ringbuf.rst
> @@ -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
> 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
> 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
> @@ -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
> 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.
> -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
> tricks like "notify only every Nth sample", which are necessary with perf
> buffer. For extreme cases, when BPF program wants more manual control of
Thanks,
Mauro
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-09-11 6:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-10 22:52 [PATCH bpf] docs/bpf: fix ringbuf documentation Andrii Nakryiko
2020-09-11 3:19 ` Alexei Starovoitov
2020-09-11 6:38 ` Mauro Carvalho Chehab
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.