Reflow paragraphs to more fully and evenly fill 78 character lines.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Fix various typos, some of the formatting and wording for
Documentation/btf.rst.
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
This patch added documentation for BTF (BPF Debug Format).
The document is placed under linux:Documentation/bpf directory.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Update the bpf_design_QA.rst to also reflect recent changes in
6c4fc209fc ("bpf: remove useless version check for prog load").
Suggested-by: Quentin Monnet <quentin.monnet@netronome.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann says:
====================
pull-request: bpf-next 2018-08-07
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) Add cgroup local storage for BPF programs, which provides a fast
accessible memory for storing various per-cgroup data like number
of transmitted packets, etc, from Roman.
2) Support bpf_get_socket_cookie() BPF helper in several more program
types that have a full socket available, from Andrey.
3) Significantly improve the performance of perf events which are
reported from BPF offload. Also convert a couple of BPF AF_XDP
samples overto use libbpf, both from Jakub.
4) seg6local LWT provides the End.DT6 action, which allows to
decapsulate an outer IPv6 header containing a Segment Routing Header.
Adds this action now to the seg6local BPF interface, from Mathieu.
5) Do not mark dst register as unbounded in MOV64 instruction when
both src and dst register are the same, from Arthur.
6) Define u_smp_rmb() and u_smp_wmb() to their respective barrier
instructions on arm64 for the AF_XDP sample code, from Brian.
7) Convert the tcp_client.py and tcp_server.py BPF selftest scripts
over from Python 2 to Python 3, from Jeremy.
8) Enable BTF build flags to the BPF sample code Makefile, from Taeung.
9) Remove an unnecessary rcu_read_lock() in run_lwt_bpf(), from Taehee.
10) Several improvements to the README.rst from the BPF documentation
to make it more consistent with RST format, from Tobin.
11) Replace all occurrences of strerror() by calls to strerror_r()
in libbpf and fix a FORTIFY_SOURCE build error along with it,
from Thomas.
12) Fix a bug in bpftool's get_btf() function to correctly propagate
an error via PTR_ERR(), from Yue.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The majority of files in the kernel documentation index use
capitalisation for all words, especially the shorter ones. BPF docs
better fit in with the rest of the documentation if the heading is all
capitalised.
Capitalise document heading.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Recently bpf/ docs were converted to us RST format. bp/index.rst was
created out of README but toctree was not added to include files within
Documentation/bpf/
Add toctree to Documentation/bpf/index.rst
Signed-off-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Recently bpf/ docs were converted to use RST format. 'README.rst' was
created but in order to fit in with the Sphinx build system this file
should be named 'index.rst'. Rename file, fixes to integrate into
Sphinx build system in following patches.
docs: Rename Documentation/bpf/README.rst to Documentation/bpf/index.rst
Signed-off-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
File 'Documentation/networking/netdev-FAQ.txt' has been converted to RST
format. We should update all links/references to point to the new file.
Update references to netdev-FAQ
Signed-off-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
I always forget howto run the BPF selftests. Thus, lets add that info
to the QA document.
Documentation was based on Cilium's documentation:
http://cilium.readthedocs.io/en/latest/bpf/#verifying-the-setup
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Same story as bpf_design_QA.rst RST format conversion.
Again thanks to Quentin Monnet <quentin.monnet@netronome.com> for
fixes and patches that have been squashed.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The RST formatting is done such that that when rendered or converted
to different formats, an automatic index with links are created to the
subsections.
Thus, the questions are created as sections (or subsections), in-order
to get the wanted auto-generated FAQ/QA index.
Special thanks to Quentin Monnet <quentin.monnet@netronome.com> who
have reviewed and corrected both RST formatting and GitHub rendering
issues in this file. Those commits have been squashed.
I've manually tested that this also renders nicely if included as part
of the kernel 'make htmldocs'. As the end-goal is for this to become
more integrated with kernel-doc project/movement.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This will cause them to get auto rendered, e.g. when viewing them on GitHub.
Followup patches will correct the content to be RST compliant.
Also adjust README.rst to point to the renamed files.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
A README.rst file in a directory have special meaning for sites like
github, which auto renders the contents. Plus search engines like
Google also index these README.rst files.
Auto rendering allow us to use links, for (re)directing eBPF users to
other places where docs live. The end-goal would be to direct users
towards https://www.kernel.org/doc/html/latest but we haven't written
the full docs yet, so we start out small and take this incrementally.
This directory itself contains some useful docs, which can be linked
to from the README.rst file (verified this works for github).
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
BPF_PROG_TYPE_SK_MSG programs use a 'void *' for both data and the
data_end pointers. Additionally, the verifier ensures that every
accesses into the values is a __u64 read. This correctly maps on
to the BPF 64-bit architecture.
However, to ensure that when building on 32bit architectures that
clang uses correct types the '-target bpf' option _must_ be
specified. To make this clear add a note to the Documentation.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
As this recently came up on netdev [0], lets add it to the BPF devel doc.
[0] https://www.spinics.net/lists/netdev/msg489612.html
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The added documentation explains how generated codes may differ
between clang bpf target and default target, and when to use
each target.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
In the same spirit of netdev FAQ, start a BPF FAQ as a collection
of expectations and/or workflow details in the context of BPF patch
processing.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
to address common misconceptions about what BPF is and what it's not
add short BPF Q&A that clarifies core BPF design principles and
answers some common questions.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
