From: sdf@google.com
To: dthaler1968@googlemail.com
Cc: bpf@vger.kernel.org, Dave Thaler <dthaler@microsoft.com>
Subject: Re: [PATCH 4/4] bpf, docs: Explain helper functions
Date: Wed, 19 Oct 2022 13:54:26 -0700 [thread overview]
Message-ID: <Y1BkAjUts2WQdeTm@google.com> (raw)
In-Reply-To: <20221019183845.905-4-dthaler1968@googlemail.com>
On 10/19, dthaler1968@googlemail.com wrote:
> From: Dave Thaler <dthaler@microsoft.com>
> Explain helper functions.
> Kernel functions and bpf to bpf calls are covered in
> a later commit in this set ("Add extended call instructions").
> Signed-off-by: Dave Thaler <dthaler@microsoft.com>
> ---
> Documentation/bpf/instruction-set.rst | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
> diff --git a/Documentation/bpf/instruction-set.rst
> b/Documentation/bpf/instruction-set.rst
> index 29b599c70..f9e56d9d5 100644
> --- a/Documentation/bpf/instruction-set.rst
> +++ b/Documentation/bpf/instruction-set.rst
> @@ -242,7 +242,7 @@ BPF_JSET 0x40 PC += off if dst & src
> BPF_JNE 0x50 PC += off if dst != src
> BPF_JSGT 0x60 PC += off if dst > src signed
> BPF_JSGE 0x70 PC += off if dst >= src signed
> -BPF_CALL 0x80 function call
> +BPF_CALL 0x80 function call see `Helper functions`_
> BPF_EXIT 0x90 function / program return BPF_JMP only
> BPF_JLT 0xa0 PC += off if dst < src unsigned
> BPF_JLE 0xb0 PC += off if dst <= src unsigned
> @@ -253,6 +253,22 @@ BPF_JSLE 0xd0 PC += off if dst <= src signed
> The eBPF program needs to store the return value into register R0 before
> doing a
> BPF_EXIT.
> +Helper functions
> +~~~~~~~~~~~~~~~~
> +Helper functions are a concept whereby BPF programs can call into a
> +set of function calls exposed by the eBPF runtime. Each helper
(the series looks good to me, but I'm assuming Alexei will take a look at
these anywey because he did for the previous submissions)
Not really related to the patch, but in general, quoting from the above:
"BPF programs can call ... by the eBPF runtime". I know we do it all the
time
and use BPF/eBPF interchangeably, but should we try to be consistent at
least
within the same page?
$ grep -r 'eBPF program' Documentation/bpf/ | wc -l
34
$ grep -r ' BPF program' Documentation/bpf/ | wc -l
97
> +function is identified by an integer used in a ``BPF_CALL`` instruction.
> +The available helper functions may differ for each eBPF program type.
> +
> +Conceptually, each helper function is implemented with a commonly shared
> function
> +signature defined as:
> +
> + u64 function(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +
> +In actuality, each helper function is defined as taking between 0 and 5
> arguments,
> +with the remaining registers being ignored. The definition of a helper
> function
> +is responsible for specifying the type (e.g., integer, pointer, etc.) of
> the value returned,
> +the number of arguments, and the type of each argument.
> Load and store instructions
> ===========================
> --
> 2.33.4
next prev parent reply other threads:[~2022-10-19 20:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 18:38 [PATCH 1/4] bpf, docs: Add note about type convention dthaler1968
2022-10-19 18:38 ` [PATCH 2/4] bpf, docs: Fix modulo zero, division by zero, overflow, and underflow dthaler1968
2022-10-19 18:38 ` [PATCH 3/4] bpf, docs: Use consistent names for the same field dthaler1968
2022-10-19 20:57 ` sdf
2022-10-19 21:06 ` Dave Thaler
2022-10-19 23:33 ` Stanislav Fomichev
2022-10-19 23:37 ` Alexei Starovoitov
2022-10-21 17:56 ` Dave Thaler
2022-10-21 18:35 ` Stanislav Fomichev
2022-10-21 19:01 ` Alexei Starovoitov
2022-10-21 19:24 ` Dave Thaler
2022-10-21 20:07 ` Alexei Starovoitov
2022-10-19 18:38 ` [PATCH 4/4] bpf, docs: Explain helper functions dthaler1968
2022-10-19 20:54 ` sdf [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-10-27 14:39 [PATCH 1/4] bpf, docs: Add note about type convention dthaler1968
2022-10-27 14:39 ` [PATCH 4/4] bpf, docs: Explain helper functions dthaler1968
2022-11-09 1:51 ` Alexei Starovoitov
2022-11-09 10:30 ` Dave Thaler
2022-11-09 19:10 ` Alexei Starovoitov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1BkAjUts2WQdeTm@google.com \
--to=sdf@google.com \
--cc=bpf@vger.kernel.org \
--cc=dthaler1968@googlemail.com \
--cc=dthaler@microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.