BPF List
 help / color / mirror / Atom feed
From: dthaler1968@googlemail.com
To: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>
Cc: <bpf@vger.kernel.org>, <bpf@ietf.org>
Subject: RE: [Bpf] [PATCH bpf-next v2] bpf, docs: Add callx instructions in new conformance group
Date: Mon, 12 Feb 2024 13:46:14 -0800	[thread overview]
Message-ID: <036201da5dfc$e7289830$b579c890$@gmail.com> (raw)
In-Reply-To: <87le7ptlsq.fsf@oracle.com>

Jose E. Marchesi <jose.marchesi@oracle.com> writes:
> > +BPF_CALL  0x8    0x1  call PC += reg_val(imm)          BPF_JMP | BPF_X
only,
> see `Program-local functions`_
> 
> If the instruction requires a register operand, why not using one of the
> register fields?  Is there any reason for not doing that?

Yeah, the reason is because this is document what clang has done by default
for a long time now.  The IETF WG charter says:

> The BPF working group is initially tasked with documenting the existing
> state of the BPF ecosystem

So extensions can always add new instructions and deprecate old ones
but the initial version of the ISA needs to document "the existing state
of the BPF ecosystem".  I know gcc used a different field but one has to
go out of your way to specify a command line option to get that to happen,
whereas clang uses callx as documented when you don't do -O2, without
requiring any extra command line options.

I agree with you that it would have been better to use the src register
since the BPF_X bit is supposed to mean that, but that ship apparently
sailed long ago with clang.

Dave


WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: "'Jose E. Marchesi'" <jose.marchesi@oracle.com>
Cc: <bpf@vger.kernel.org>, <bpf@ietf.org>
Subject: Re: [Bpf] [PATCH bpf-next v2] bpf, docs: Add callx instructions in new conformance group
Date: Mon, 12 Feb 2024 13:46:14 -0800	[thread overview]
Message-ID: <036201da5dfc$e7289830$b579c890$@gmail.com> (raw)
Message-ID: <20240212214614.oy3qJL9cSxl9YX3GphJfCzW0D2N5t-Lo_2LYm9cS5wE@z> (raw)
In-Reply-To: <87le7ptlsq.fsf@oracle.com>

Jose E. Marchesi <jose.marchesi@oracle.com> writes:
> > +BPF_CALL  0x8    0x1  call PC += reg_val(imm)          BPF_JMP | BPF_X
only,
> see `Program-local functions`_
> 
> If the instruction requires a register operand, why not using one of the
> register fields?  Is there any reason for not doing that?

Yeah, the reason is because this is document what clang has done by default
for a long time now.  The IETF WG charter says:

> The BPF working group is initially tasked with documenting the existing
> state of the BPF ecosystem

So extensions can always add new instructions and deprecate old ones
but the initial version of the ISA needs to document "the existing state
of the BPF ecosystem".  I know gcc used a different field but one has to
go out of your way to specify a command line option to get that to happen,
whereas clang uses callx as documented when you don't do -O2, without
requiring any extra command line options.

I agree with you that it would have been better to use the src register
since the BPF_X bit is supposed to mean that, but that ship apparently
sailed long ago with clang.

Dave

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

  parent reply	other threads:[~2024-02-12 21:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 21:13 [PATCH bpf-next v2] bpf, docs: Add callx instructions in new conformance group Dave Thaler
2024-02-12 21:13 ` [Bpf] " Dave Thaler
2024-02-12 21:21 ` David Vernet
2024-02-12 21:21   ` David Vernet
2024-02-12 21:28 ` Jose E. Marchesi
2024-02-12 21:28   ` Jose E. Marchesi
2024-02-12 21:46   ` dthaler1968 [this message]
2024-02-12 21:46     ` dthaler1968=40googlemail.com
2024-02-12 21:49   ` Yonghong Song
2024-02-12 21:49     ` Yonghong Song
2024-02-12 21:52     ` dthaler1968
2024-02-12 21:52       ` dthaler1968=40googlemail.com
2024-02-12 22:48       ` Yonghong Song
2024-02-12 22:48         ` Yonghong Song
2024-02-13  1:18         ` dthaler1968
2024-02-13  1:18           ` dthaler1968=40googlemail.com
2024-02-13  1:23           ` Yonghong Song
2024-02-13  1:23             ` Yonghong Song
2024-02-13  6:11         ` Jose E. Marchesi
2024-02-13  6:11           ` Jose E. Marchesi

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='036201da5dfc$e7289830$b579c890$@gmail.com' \
    --to=dthaler1968@googlemail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox