All of lore.kernel.org
 help / color / mirror / Atom feed
From: dthaler1968@googlemail.com
To: "'Alexei Starovoitov'" <alexei.starovoitov@gmail.com>
Cc: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>,
	"'Yonghong Song'" <yonghong.song@linux.dev>, <bpf@ietf.org>,
	"'bpf'" <bpf@vger.kernel.org>
Subject: RE: [Bpf] ISA: BPF_MSH and deprecated packet access instructions
Date: Tue, 30 Jan 2024 07:51:10 -0800	[thread overview]
Message-ID: <071b01da5394$260dba30$72292e90$@gmail.com> (raw)
In-Reply-To: <CAADnVQK8JegsSxgbQbO=DR71cRgkvN-y9LH_ZQYxmj1a-hCz5g@mail.gmail.com>

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
[...]
> > Although the Linux verifier doesn't support them, the fact that gcc
> > does support them tells me that it's probably safest to list the DW
> > and LDX variants as deprecated as well, which is what the draft
> > already did in the appendix so that's good (nothing to change there, I
> > think).
> 
> DW never existed in classic bpf, so abs/ind never had DW flavor.
> If some assembler/compiler decided to "support" them it's on them.
> The standard must not list such things as deprecated. They never existed. So
> nothing is deprecated.

Ack, I will remove the ABS/IND + DW lines from the appendix.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

Should it be listed in the legacy conformance group then?

Currently it's not mentioned in instruction-set.rst at all, so the opcode
is available to use by any new instruction.  If we do list it in instruction-set.rst
then, like abs/ind, it will be avoided by anyone proposing new instructions.

Dave


WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: "'Alexei Starovoitov'" <alexei.starovoitov@gmail.com>
Cc: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>,
	"'Yonghong Song'" <yonghong.song@linux.dev>, <bpf@ietf.org>,
	"'bpf'" <bpf@vger.kernel.org>
Subject: Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions
Date: Tue, 30 Jan 2024 07:51:10 -0800	[thread overview]
Message-ID: <071b01da5394$260dba30$72292e90$@gmail.com> (raw)
Message-ID: <20240130155110.7t6OaAtBS1PulMNUcjULDJpRsDshfPtI_rwiAfuGeXw@z> (raw)
In-Reply-To: <CAADnVQK8JegsSxgbQbO=DR71cRgkvN-y9LH_ZQYxmj1a-hCz5g@mail.gmail.com>

Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
[...]
> > Although the Linux verifier doesn't support them, the fact that gcc
> > does support them tells me that it's probably safest to list the DW
> > and LDX variants as deprecated as well, which is what the draft
> > already did in the appendix so that's good (nothing to change there, I
> > think).
> 
> DW never existed in classic bpf, so abs/ind never had DW flavor.
> If some assembler/compiler decided to "support" them it's on them.
> The standard must not list such things as deprecated. They never existed. So
> nothing is deprecated.

Ack, I will remove the ABS/IND + DW lines from the appendix.

> Same with MSH. BPF_LDX | BPF_MSH | BPF_B is the only insn ever existed.
> It's a legacy insn. Just like abs/ind.

Should it be listed in the legacy conformance group then?

Currently it's not mentioned in instruction-set.rst at all, so the opcode
is available to use by any new instruction.  If we do list it in instruction-set.rst
then, like abs/ind, it will be avoided by anyone proposing new instructions.

Dave

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

  parent reply	other threads:[~2024-01-30 15:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27 18:50 ISA: BPF_MSH and deprecated packet access instructions dthaler1968
2024-01-27 18:50 ` [Bpf] " dthaler1968=40googlemail.com
2024-01-27 18:59 ` Jose E. Marchesi
2024-01-27 18:59   ` Jose E. Marchesi
2024-01-27 19:06   ` Jose E. Marchesi
2024-01-27 19:06     ` Jose E. Marchesi
2024-01-28  6:59     ` dthaler1968
2024-01-28  6:59       ` dthaler1968=40googlemail.com
2024-01-28 23:59       ` Alexei Starovoitov
2024-01-28 23:59         ` Alexei Starovoitov
2024-01-29 12:07         ` Jose E. Marchesi
2024-01-29 12:07           ` Jose E. Marchesi
2024-01-30 12:13           ` Jose E. Marchesi
2024-01-30 12:13             ` Jose E. Marchesi
2024-01-30 15:51         ` dthaler1968 [this message]
2024-01-30 15:51           ` dthaler1968=40googlemail.com
2024-01-30 16:22           ` Alexei Starovoitov
2024-01-30 16:22             ` Alexei Starovoitov
2024-01-30 16:42             ` dthaler1968
2024-01-30 16:42               ` dthaler1968=40googlemail.com
2024-01-30 16:39           ` dthaler1968
2024-01-30 16:39             ` dthaler1968=40googlemail.com
2024-01-30 18:39             ` Yonghong Song
2024-01-30 18:39               ` Yonghong Song
2024-01-30 19:40             ` Alexei Starovoitov
2024-01-30 19:40               ` Alexei Starovoitov
2024-01-28  0:26 ` Yonghong Song
2024-01-28  0:26   ` [Bpf] " Yonghong Song
2024-01-28  0:53   ` dthaler1968
2024-01-28  0:53     ` [Bpf] " dthaler1968=40googlemail.com
2024-01-28  1:24     ` Yonghong Song
2024-01-28  1:24       ` [Bpf] " Yonghong Song

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='071b01da5394$260dba30$72292e90$@gmail.com' \
    --to=dthaler1968@googlemail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=jose.marchesi@oracle.com \
    --cc=yonghong.song@linux.dev \
    /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.