BPF List
 help / color / mirror / Atom feed
From: dthaler1968@googlemail.com
To: "'David Vernet'" <void@manifault.com>,
	"'Jose E. Marchesi'" <jose.marchesi@oracle.com>
Cc: "'Alexei Starovoitov'" <alexei.starovoitov@gmail.com>,
	"'Christoph Hellwig'" <hch@infradead.org>, <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, 23 Jan 2024 15:29:41 -0800	[thread overview]
Message-ID: <1f8301da4e54$0b0ad690$212083b0$@gmail.com> (raw)
In-Reply-To: <20240123213948.GA221862@maniforge>

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Tuesday, January 23, 2024 1:40 PM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>; Christoph Hellwig
> <hch@infradead.org>; 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
> 
> On Tue, Jan 09, 2024 at 12:35:39PM +0100, Jose E. Marchesi wrote:
> >
> > > 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.
> this is necessarily something we need to figure out now. Hopefully this is all
> stuff we can iron out once we start to really sink our teeth into the ABI doc.

"Integer Multiplication and Division" in this thread doesn't seem to separate
between 32-bit vs 64-bit.  Is the proposal that multiplication/division is ok
to require 64-bit operations?  I had expected one rationale for the 32bit
multiplication/division instructions is to accommodate 32-bit-only
implementations.   So should we have separate groups for 32-bit vs
64-bit for the multiplication/division instructions?

Similar question goes for the atomic instructions, i.e., should we
have separate conformance groups for 32-bit vs 64-bit atomics? 

Dave


WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: "'David Vernet'" <void@manifault.com>,
	"'Jose E. Marchesi'" <jose.marchesi@oracle.com>
Cc: "'Alexei Starovoitov'" <alexei.starovoitov@gmail.com>,
	"'Christoph Hellwig'" <hch@infradead.org>, <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, 23 Jan 2024 15:29:41 -0800	[thread overview]
Message-ID: <1f8301da4e54$0b0ad690$212083b0$@gmail.com> (raw)
Message-ID: <20240123232941.rw2hxRqPx5OJlt--OF0Xm4W52pxKNe-AFR3xryT_mg4@z> (raw)
In-Reply-To: <20240123213948.GA221862@maniforge>

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Tuesday, January 23, 2024 1:40 PM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>
> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>; Christoph Hellwig
> <hch@infradead.org>; 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
> 
> On Tue, Jan 09, 2024 at 12:35:39PM +0100, Jose E. Marchesi wrote:
> >
> > > 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.
> this is necessarily something we need to figure out now. Hopefully this is all
> stuff we can iron out once we start to really sink our teeth into the ABI doc.

"Integer Multiplication and Division" in this thread doesn't seem to separate
between 32-bit vs 64-bit.  Is the proposal that multiplication/division is ok
to require 64-bit operations?  I had expected one rationale for the 32bit
multiplication/division instructions is to accommodate 32-bit-only
implementations.   So should we have separate groups for 32-bit vs
64-bit for the multiplication/division instructions?

Similar question goes for the atomic instructions, i.e., should we
have separate conformance groups for 32-bit vs 64-bit atomics? 

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

  parent reply	other threads:[~2024-01-23 23:29 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
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 [this message]
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='1f8301da4e54$0b0ad690$212083b0$@gmail.com' \
    --to=dthaler1968@googlemail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=david.faust@oracle.com \
    --cc=hch@infradead.org \
    --cc=jose.marchesi@oracle.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox