| Message ID | 20221027143914.1928-4-dthaler1968@googlemail.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | BPF |
| Headers | show |
| Series | [1/4] bpf, docs: Add note about type convention | expand |
On Thu, Oct 27, 2022 at 7:46 AM <dthaler1968@googlemail.com> wrote: > > From: Dave Thaler <dthaler@microsoft.com> > > Explain helper functions > > 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 aa1b37cb5..40c3293d6 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 eBPF right next to BPF looks odd. Let's stick to BPF everywhere?
> -----Original Message----- > From: Alexei Starovoitov <alexei.starovoitov@gmail.com> > Sent: Wednesday, November 9, 2022 1:51 AM > To: dthaler1968@googlemail.com > Cc: bpf <bpf@vger.kernel.org>; Dave Thaler <dthaler@microsoft.com> > Subject: Re: [PATCH 4/4] bpf, docs: Explain helper functions > > On Thu, Oct 27, 2022 at 7:46 AM <dthaler1968@googlemail.com> wrote: > > > > From: Dave Thaler <dthaler@microsoft.com> > > > > Explain helper functions > > > > 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 aa1b37cb5..40c3293d6 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 > > eBPF right next to BPF looks odd. Let's stick to BPF everywhere? Since the brand is eBPF, could we stick to eBPF everywhere except the actual defines (BPF_CALL, etc. have to be literal)? Dave
On Wed, Nov 9, 2022 at 2:30 AM Dave Thaler <dthaler@microsoft.com> wrote: > > > -----Original Message----- > > From: Alexei Starovoitov <alexei.starovoitov@gmail.com> > > Sent: Wednesday, November 9, 2022 1:51 AM > > To: dthaler1968@googlemail.com > > Cc: bpf <bpf@vger.kernel.org>; Dave Thaler <dthaler@microsoft.com> > > Subject: Re: [PATCH 4/4] bpf, docs: Explain helper functions > > > > On Thu, Oct 27, 2022 at 7:46 AM <dthaler1968@googlemail.com> wrote: > > > > > > From: Dave Thaler <dthaler@microsoft.com> > > > > > > Explain helper functions > > > > > > 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 aa1b37cb5..40c3293d6 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 > > > > eBPF right next to BPF looks odd. Let's stick to BPF everywhere? > > Since the brand is eBPF, could we stick to eBPF everywhere except the > actual defines (BPF_CALL, etc. have to be literal)? I prefer to use BPF everywhere.
diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index aa1b37cb5..40c3293d6 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 +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 ===========================