From: Christoph Hellwig <hch@infradead.org>
To: David Vernet <void@manifault.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Dave Thaler <dthaler1968@googlemail.com>,
bpf@ietf.org, bpf <bpf@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Thu, 14 Dec 2023 21:29:47 -0800 [thread overview]
Message-ID: <ZXvkS4qmRMZqlWhA@infradead.org> (raw)
In-Reply-To: <20231214174437.GA2853@maniforge>
On Thu, Dec 14, 2023 at 11:44:37AM -0600, David Vernet wrote:
> > > Why else would they be asking for a standard if not to
> > > have some guidelines of what to implement?
> >
> > Excellent question. I don't know why nvme folks need a standard.
> > Lack of standard didn't stop netronome.
>
> Christoph? Any chance you can shed some light here?
netronome is a single vendor implementation. You write for their
device and the standard is what they accept. NVMe is an open,
multi-vendor standard. You need to be able to write your code against
the spec and run it on all devices (that implement the required
features). NVMe also needs another open standard as the reference as
it just can't point to a void.
> I agree that there's value in instructions having specific meaning and
> encodings, but my worry is that (for device offload) the value would be
> minimized quite a bit if a developer writing a BPF offload program
> doesn't also have some knowledge or guarantee of what instructions
> vendors have actually implemented.
Absolutely.
> If we were to do away with conformance groups, then I as a BPF user
> would have the guarantee: "Any hw device which happens to implement the
> instructions in my program will behave in a predictable way". If that
> user doesn't know what instructions it can count on being actually
> available in devices, then they're going to end up just implementing the
> program for a single device anyways. At that point, how useful was it
> really to standardize on the semantics of the instructions? That user
> just as soon could have read the specifications for the device and
> implemented the prog according to the semantics that the vendor decided
> were most appropriate for them.
We need the concept in the spec just to allow future extensability.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: David Vernet <void@manifault.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Dave Thaler <dthaler1968@googlemail.com>,
bpf@ietf.org, bpf <bpf@vger.kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [Bpf] BPF ISA conformance groups
Date: Thu, 14 Dec 2023 21:29:47 -0800 [thread overview]
Message-ID: <ZXvkS4qmRMZqlWhA@infradead.org> (raw)
Message-ID: <20231215052947.pgVfdr4s9MrGXbORqqPX72kF83qnYuqPFf3xJ_19iK4@z> (raw)
In-Reply-To: <20231214174437.GA2853@maniforge>
On Thu, Dec 14, 2023 at 11:44:37AM -0600, David Vernet wrote:
> > > Why else would they be asking for a standard if not to
> > > have some guidelines of what to implement?
> >
> > Excellent question. I don't know why nvme folks need a standard.
> > Lack of standard didn't stop netronome.
>
> Christoph? Any chance you can shed some light here?
netronome is a single vendor implementation. You write for their
device and the standard is what they accept. NVMe is an open,
multi-vendor standard. You need to be able to write your code against
the spec and run it on all devices (that implement the required
features). NVMe also needs another open standard as the reference as
it just can't point to a void.
> I agree that there's value in instructions having specific meaning and
> encodings, but my worry is that (for device offload) the value would be
> minimized quite a bit if a developer writing a BPF offload program
> doesn't also have some knowledge or guarantee of what instructions
> vendors have actually implemented.
Absolutely.
> If we were to do away with conformance groups, then I as a BPF user
> would have the guarantee: "Any hw device which happens to implement the
> instructions in my program will behave in a predictable way". If that
> user doesn't know what instructions it can count on being actually
> available in devices, then they're going to end up just implementing the
> program for a single device anyways. At that point, how useful was it
> really to standardize on the semantics of the instructions? That user
> just as soon could have read the specifications for the device and
> implemented the prog according to the semantics that the vendor decided
> were most appropriate for them.
We need the concept in the spec just to allow future extensability.
--
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf
next prev parent reply other threads:[~2023-12-15 5: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 [this message]
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
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=ZXvkS4qmRMZqlWhA@infradead.org \
--to=hch@infradead.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=dthaler1968@googlemail.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