bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Dave Thaler <dthaler@microsoft.com>
Cc: "bpf@ietf.org" <bpf@ietf.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [Bpf] ISA RFC compliance question
Date: Fri, 6 Oct 2023 16:06:53 -0700	[thread overview]
Message-ID: <CAADnVQ+BOdrU4x3qKHJVbpZCJwTWe6HXWhuMqOk-x5UK22yPDQ@mail.gmail.com> (raw)
Message-ID: <20231006230653.EA5rGPsRtzmZklHE42NpAnCSjXewY0quffAy7h69YXY@z> (raw)
In-Reply-To: <PH7PR21MB3878A25F817337EF14FE039FA3CAA@PH7PR21MB3878.namprd21.prod.outlook.com>

On Thu, Oct 5, 2023 at 1:14 PM Dave Thaler <dthaler@microsoft.com> wrote:
>
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > On Fri, Sep 29, 2023 at 1:17 PM Dave Thaler
> > <dthaler=40microsoft.com@dmarc.ietf.org> wrote:
> > > Now that we have some new "v4" instructions, it seems a good time to
> > > ask about what it means to support (or comply with) the ISA RFC once
> > > published.  Does it mean that a verifier/disassembler/JIT compiler/etc. MUST
> > support *all* the
> > > non-deprecated instructions in the document?   That is any runtime or tool that
> > > doesn't support the new instructions is considered non-compliant with the BPF
> > ISA?
> [...]
> > > Or should we create some things that are SHOULDs, or finer grained
> > > units of compliance so as to not declare existing deployments non-compliant?
> >
> > I suspect 'non-compliance' label will cause an unnecessary backlash, so I would
> > go with SHOULD wording.
>
> Yeah, but if each instruction is a separate SHOULD, then a runtime could (say)
> support one atomic instruction and not others.  Having that level of granularity
> would really complicate interoperability and cross-platform tooling in my opinion.
> So it might be better to list groups of instructions and have the SHOULD be at the
> granularity of a group?

I guess we can group them based on LLVM evolution of the instruction set:
-mcpu=v1,v2,v3,v4
but it would have mainly historical benefits and not practical.
Grouping atomic vs not is not realistic either, since atomic_xadd
was there since the very beginning.
I suspect any kind of grouping scheme will end up in bike shedding.
My preference would be to agree on either SHOULD or MUST for
all insns currently described in ISA doc.
We can go with MUST to force compliance.
Some archs, OSes, JITs won't be compliant in the short term,
but MUST wording will be a good motivation to do the work now instead of later.

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

  parent reply	other threads:[~2023-10-06 23:07 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 20:14 [Bpf] ISA RFC compliance question Dave Thaler
2023-09-29 20:17 ` Dave Thaler
2023-09-29 20:17   ` [Bpf] " Dave Thaler
2023-09-30 15:48   ` Alexei Starovoitov
2023-09-30 15:48     ` Alexei Starovoitov
2023-10-05 20:14     ` Dave Thaler
2023-10-05 20:14       ` Dave Thaler
2023-10-06 23:06       ` Alexei Starovoitov [this message]
2023-10-06 23:06         ` Alexei Starovoitov
2023-10-23 22:15         ` David Vernet
2023-10-23 22:15           ` David Vernet
2023-10-19  6:02 ` Christoph Hellwig
2023-10-19  6:02   ` Christoph Hellwig
2023-10-23 15:06   ` Will Hawkins
2023-10-23 15:06     ` Will Hawkins
2023-10-24  4:00     ` Christoph Hellwig
2023-10-24  4:00       ` 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=CAADnVQ+BOdrU4x3qKHJVbpZCJwTWe6HXWhuMqOk-x5UK22yPDQ@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=dthaler@microsoft.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;
as well as URLs for NNTP newsgroup(s).