From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
David Vernet <void@manifault.com>,
Dave Thaler <dthaler1968@googlemail.com>,
bpf@ietf.org, bpf <bpf@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
david.faust@oracle.com
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Tue, 09 Jan 2024 12:35:39 +0100 [thread overview]
Message-ID: <874jfm68ok.fsf@oracle.com> (raw)
In-Reply-To: <CAADnVQLMo0M675T89gu9v_wSR+GbQmu4ajWjwgWK9aCNkJPsaQ@mail.gmail.com> (Alexei Starovoitov's message of "Mon, 8 Jan 2024 13:51:21 -0800")
> On Mon, Jan 8, 2024 at 8:00 AM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Fri, Jan 05, 2024 at 04:07:11PM -0600, David Vernet wrote:
>> >
>> > So how do we want to move forward here? It sounds like we're leaning
>> > toward's Alexei's proposal of having:
>> >
>> > - Base Integer Instruction Set, 32-bit
>> > - Base Integer Instruction Set, 64-bit
>> > - Integer Multiplication and Division
>> > - Atomic Instructions
>>
>> As in the 64-bit integer set would be an add-on to the first one which
>> is the core set? In that case that's fine with me, but the above
>> wording is a bit suboptimal.
>
> yes.
> Here is how I was thinking about the grouping:
> 32-bit set: all 32-bit instructions those with BPF_ALU and BPF_JMP32
> and load/store.
>
> 64-bit set: above plus BPF_ALU64 and BPF_JMP.
>
> The idea is to allow for clean 32-bit HW offloads.
> We can introduce a compiler flag that will only use such instructions
> and will error when 64-bit math is needed.
> Details need to be thought through, of course.
> Right now I'm not sure whether we need to reduce sizeof(void*) to 4
> in such a case or normal 8 will still work, but from ISA perspective
> everything is ready. 32-bit subregisters fit well.
> The compiler work plus additional verifier smartness is needed,
> but the end result should be very nice.
> Offload of bpf programs into 32-bit embedded devices will be possible.
This is very interesting.
Sounds like, on one hand, introducing ilp32 and lp64 C data models for
BPF:
ilp32
int, long, pointers -> 32 bit
short -> 16 bit
char -> 8 bit
lp64
long, pointers -> 64 bit
int -> 32 bit
short -> 16 bit
char -> 8 bit
On the other hand, compiler flags -m32 and -m64 could determine what
instruction groups are generated and what C data model is used:
-m32
Use ilp32 data model for C.
Use 32-bit instruction set.
-m64
Use lp64 data model for C.
Use both 32-bit (if/when alu32) and 64-bit instruction sets.
And perhaps introducing a bit in the ELF flags section identifying a
32-bit binary. Something like EF_BPF_32.
Would 64-bit ELF be used also in cases where BPF is offloaded to 32-bit
devices?
>> > And then either having 3 separate groups for the calls, or putting all 3
>> > in the basic group? I'd lean towards the latter given that we're
>> > decoupling ISA compliance from the verifier, but don't feel strongly
>> > either way.
>>
>> What would be the three different groups for the calls? I think just
>> having the call instruction in the base group should be fine. We'll
>> need to put in some wording that having support for any kind of call
>> depends on the program type.
>
> +1
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
WARNING: multiple messages have this Message-ID (diff)
From: "Jose E. Marchesi" <jose.marchesi@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
David Vernet <void@manifault.com>,
Dave Thaler <dthaler1968@googlemail.com>,
bpf@ietf.org, bpf <bpf@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
david.faust@oracle.com
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Tue, 09 Jan 2024 12:35:39 +0100 [thread overview]
Message-ID: <874jfm68ok.fsf@oracle.com> (raw)
Message-ID: <20240109113539.aZvO0sEu4hcmdXJirgsKwvHGOL17OfOnUn8Vh6WVtRQ@z> (raw)
In-Reply-To: <CAADnVQLMo0M675T89gu9v_wSR+GbQmu4ajWjwgWK9aCNkJPsaQ@mail.gmail.com> (Alexei Starovoitov's message of "Mon, 8 Jan 2024 13:51:21 -0800")
> On Mon, Jan 8, 2024 at 8:00 AM Christoph Hellwig <hch@infradead.org> wrote:
>>
>> On Fri, Jan 05, 2024 at 04:07:11PM -0600, David Vernet wrote:
>> >
>> > So how do we want to move forward here? It sounds like we're leaning
>> > toward's Alexei's proposal of having:
>> >
>> > - Base Integer Instruction Set, 32-bit
>> > - Base Integer Instruction Set, 64-bit
>> > - Integer Multiplication and Division
>> > - Atomic Instructions
>>
>> As in the 64-bit integer set would be an add-on to the first one which
>> is the core set? In that case that's fine with me, but the above
>> wording is a bit suboptimal.
>
> yes.
> Here is how I was thinking about the grouping:
> 32-bit set: all 32-bit instructions those with BPF_ALU and BPF_JMP32
> and load/store.
>
> 64-bit set: above plus BPF_ALU64 and BPF_JMP.
>
> The idea is to allow for clean 32-bit HW offloads.
> We can introduce a compiler flag that will only use such instructions
> and will error when 64-bit math is needed.
> Details need to be thought through, of course.
> Right now I'm not sure whether we need to reduce sizeof(void*) to 4
> in such a case or normal 8 will still work, but from ISA perspective
> everything is ready. 32-bit subregisters fit well.
> The compiler work plus additional verifier smartness is needed,
> but the end result should be very nice.
> Offload of bpf programs into 32-bit embedded devices will be possible.
This is very interesting.
Sounds like, on one hand, introducing ilp32 and lp64 C data models for
BPF:
ilp32
int, long, pointers -> 32 bit
short -> 16 bit
char -> 8 bit
lp64
long, pointers -> 64 bit
int -> 32 bit
short -> 16 bit
char -> 8 bit
On the other hand, compiler flags -m32 and -m64 could determine what
instruction groups are generated and what C data model is used:
-m32
Use ilp32 data model for C.
Use 32-bit instruction set.
-m64
Use lp64 data model for C.
Use both 32-bit (if/when alu32) and 64-bit instruction sets.
And perhaps introducing a bit in the ELF flags section identifying a
32-bit binary. Something like EF_BPF_32.
Would 64-bit ELF be used also in cases where BPF is offloaded to 32-bit
devices?
>> > And then either having 3 separate groups for the calls, or putting all 3
>> > in the basic group? I'd lean towards the latter given that we're
>> > decoupling ISA compliance from the verifier, but don't feel strongly
>> > either way.
>>
>> What would be the three different groups for the calls? I think just
>> having the call instruction in the base group should be fine. We'll
>> need to put in some wording that having support for any kind of call
>> depends on the program type.
>
> +1
next prev parent reply other threads:[~2024-01-09 11:35 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 20:18 IETF 118 BPF WG summary David Vernet
2023-11-27 20:18 ` [Bpf] " David Vernet
2023-11-28 9:43 ` Michael Richardson
2023-11-28 9:43 ` Michael Richardson
2023-12-02 19:51 ` BPF ISA conformance groups dthaler1968
2023-12-02 19:51 ` [Bpf] " dthaler1968=40googlemail.com
2023-12-07 21:51 ` David Vernet
2023-12-07 21:51 ` David Vernet
2023-12-10 3:10 ` Alexei Starovoitov
2023-12-10 3:10 ` Alexei Starovoitov
2023-12-10 21:13 ` Watson Ladd
2023-12-10 21:13 ` Watson Ladd
2023-12-12 21:45 ` David Vernet
2023-12-12 21:45 ` David Vernet
2023-12-12 22:01 ` dthaler1968
2023-12-12 22:01 ` dthaler1968=40googlemail.com
2023-12-12 22:55 ` Alexei Starovoitov
2023-12-12 22:55 ` Alexei Starovoitov
2023-12-12 23:35 ` David Vernet
2023-12-12 23:35 ` David Vernet
2023-12-13 1:32 ` Alexei Starovoitov
2023-12-13 1:32 ` Alexei Starovoitov
2023-12-13 18:56 ` David Vernet
2023-12-13 18:56 ` David Vernet
2023-12-14 0:12 ` Alexei Starovoitov
2023-12-14 0:12 ` Alexei Starovoitov
2023-12-14 17:44 ` David Vernet
2023-12-14 17:44 ` David Vernet
2023-12-15 5:29 ` Christoph Hellwig
2023-12-15 5:29 ` Christoph Hellwig
2023-12-19 1:15 ` Alexei Starovoitov
2023-12-19 1:15 ` Alexei Starovoitov
2023-12-19 18:10 ` dthaler1968
2023-12-19 18:10 ` dthaler1968=40googlemail.com
2023-12-20 3:28 ` Alexei Starovoitov
2023-12-20 3:28 ` Alexei Starovoitov
2023-12-21 7:00 ` Christoph Hellwig
2023-12-21 7:00 ` Christoph Hellwig
2024-01-05 22:07 ` David Vernet
2024-01-05 22:07 ` David Vernet
2024-01-08 16:00 ` Christoph Hellwig
2024-01-08 21:51 ` Alexei Starovoitov
2024-01-08 21:51 ` Alexei Starovoitov
2024-01-09 11:35 ` Jose E. Marchesi [this message]
2024-01-09 11:35 ` Jose E. Marchesi
2024-01-23 21:39 ` David Vernet
2024-01-23 21:39 ` David Vernet
2024-01-23 23:29 ` dthaler1968
2024-01-23 23:29 ` dthaler1968=40googlemail.com
2024-01-25 2:55 ` Alexei Starovoitov
2024-01-25 2:55 ` Alexei Starovoitov
2024-01-09 15:26 ` Christoph Hellwig
2023-12-19 18:15 ` dthaler1968
2023-12-19 18:15 ` dthaler1968=40googlemail.com
2023-12-13 16:59 ` Christoph Hellwig
2023-12-13 16:59 ` Christoph Hellwig
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=874jfm68ok.fsf@oracle.com \
--to=jose.marchesi@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=david.faust@oracle.com \
--cc=dthaler1968@googlemail.com \
--cc=hch@infradead.org \
--cc=kuba@kernel.org \
--cc=void@manifault.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.