All of lore.kernel.org
 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

  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 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.