All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: dthaler1968@googlemail.com, bpf@ietf.org, 'bpf' <bpf@vger.kernel.org>
Cc: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>,
	'Alexei Starovoitov' <alexei.starovoitov@gmail.com>
Subject: Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions
Date: Tue, 30 Jan 2024 10:39:36 -0800	[thread overview]
Message-ID: <e6d233c1-2b01-4615-b1fb-1fa33bf158e3@linux.dev> (raw)
In-Reply-To: <073001da539a$ec1e2b00$c45a8100$@gmail.com>


On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote:
>> 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.
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>     by clang and gcc.  They should be in the legacy conformance group of deprecated
>     instructions.
>
> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc did which is now removed
>     based on this discussion.  They should NOT be in the legacy conformance group of
>     deprecated instructions because they were never defined in the first place, and
>     instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc does. They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>     never used.  I don't know whether clang or gcc generates them.  They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>     by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.

clang never generated this insn either.

>     The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>     > BPF previously introduced special instructions for access to packet data that were carried
>     > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>     I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>     should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>     But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn
is okay to prevent anybody using the same opcode.

>
> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>     never used.  They should NOT be in the legacy conformance group of deprecated instructions
>     because they were never defined in the first place.
>
> Let me know if any of the above is incorrect and I can submit a doc patch.
>
> Dave
>

WARNING: multiple messages have this Message-ID (diff)
From: Yonghong Song <yonghong.song@linux.dev>
To: dthaler1968@googlemail.com, bpf@ietf.org, 'bpf' <bpf@vger.kernel.org>
Cc: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>,
	'Alexei Starovoitov' <alexei.starovoitov@gmail.com>
Subject: Re: [Bpf] ISA: BPF_MSH and deprecated packet access instructions
Date: Tue, 30 Jan 2024 10:39:36 -0800	[thread overview]
Message-ID: <e6d233c1-2b01-4615-b1fb-1fa33bf158e3@linux.dev> (raw)
Message-ID: <20240130183936.kSIZDcn8x_TZvLwivwIUo2EE1YmAx0VspIWwYSiVCXA@z> (raw)
In-Reply-To: <073001da539a$ec1e2b00$c45a8100$@gmail.com>


On 1/30/24 8:39 AM, dthaler1968@googlemail.com wrote:
>> 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.
> Here's my understanding of this thread so far:
>
> * (IND/ABS) | (W/H/B) | LD : these are accepted by the Linux verifier and are supported
>     by clang and gcc.  They should be in the legacy conformance group of deprecated
>     instructions.
>
> * (IND/ABS) | DW | (LD/LDX) : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc did which is now removed
>     based on this discussion.  They should NOT be in the legacy conformance group of
>     deprecated instructions because they were never defined in the first place, and
>     instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B) | LDX : these are not accepted by the Linux verifier and were
>     never used.  Clang doesn't generate them but gcc does. They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * (IND/ABS) | (W/H/B/DW) | (ST/STX): these are not accepted by the Linux verifier and were
>     never used.  I don't know whether clang or gcc generates them.  They should NOT
>     be in the legacy conformance group of deprecated instructions because they were
>     never defined in the first place, and instruction-set.rst should be updated to clarify this.
>
> * MSH | B | LDX: this existed in classic BPF but does not exist in (e)BPF since it is not accepted
>     by the Linux verifier.  I don't know whether clang ever generated them, but gcc never did.

clang never generated this insn either.

>     The "Legacy BPF Packet access instructions" section of instruction-set.rst says
>     > BPF previously introduced special instructions for access to packet data that were carried
>     > over from classic BPF. However, these instructions are deprecated and should no longer be used.
>     I read Alexei's comment "It's a legacy insn. Just like abs/ind" as a possible argument that MSH|B|LDX
>     should be mentioned in instruction-set.rst, pointing to the above section, like IND/ABS do.
>     But Yonghong argued that it was never accepted by the verifier, so need not be mentioned.

It is just my opinion. Standardization is complicated. I guess adding it to the legacy insn
is okay to prevent anybody using the same opcode.

>
> * MSH | (W/H/DW) | (LD/ST/STX): These are not accepted by the Linux verifier and were
>     never used.  They should NOT be in the legacy conformance group of deprecated instructions
>     because they were never defined in the first place.
>
> Let me know if any of the above is incorrect and I can submit a doc patch.
>
> Dave
>

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

  reply	other threads:[~2024-01-30 18:39 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
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 [this message]
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=e6d233c1-2b01-4615-b1fb-1fa33bf158e3@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=dthaler1968@googlemail.com \
    --cc=jose.marchesi@oracle.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.