From: Peilin Ye <yepeilin@google.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
bpf@ietf.org, Xu Kuohai <xukuohai@huaweicloud.com>,
Eduard Zingerman <eddyz87@gmail.com>,
David Vernet <void@manifault.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
"Paul E. McKenney" <paulmck@kernel.org>,
Puranjay Mohan <puranjay@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Quentin Monnet <qmo@kernel.org>,
Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
Josh Don <joshdon@google.com>, Barret Rhoden <brho@google.com>,
Neel Natu <neelnatu@google.com>,
Benjamin Segall <bsegall@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Yingchi Long <longyingchi24s@ict.ac.cn>
Subject: Re: [PATCH bpf-next v1 8/8] bpf, docs: Update instruction-set.rst for load-acquire and store-release instructions
Date: Thu, 30 Jan 2025 07:33:07 +0000 [thread overview]
Message-ID: <Z5srM--fdH_JAgYT@google.com> (raw)
In-Reply-To: <CAADnVQ+hi3918DUyA7bs4Va9NdNqXJg-R4A45n_MHGTikYaOSA@mail.gmail.com>
+Cc: Yingchi Long
On Wed, Jan 29, 2025 at 04:44:02PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 24, 2025 at 6:19 PM Peilin Ye <yepeilin@google.com> wrote:
> > +Atomic load and store operations
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +To encode an atomic load or store operation, the lowest 8 bits of the 'imm'
> > +field are divided as follows::
> > +
> > + +-+-+-+-+-+-+-+-+
> > + | type | order |
> > + +-+-+-+-+-+-+-+-+
> > +
> > +**type**
> > + The operation type is one of:
> > +
> > +.. table:: Atomic load and store operation types
> > +
> > + ============ ===== ============
> > + type value description
> > + ============ ===== ============
> > + ATOMIC_LOAD 0x1 atomic load
> > + ATOMIC_STORE 0x2 atomic store
> > + ============ ===== ============
> > +
> > +**order**
> > + The memory order is one of:
> > +
> > +.. table:: Memory orders
> > +
> > + ======= ===== =======================
> > + order value description
> > + ======= ===== =======================
> > + RELAXED 0x0 relaxed
> > + ACQUIRE 0x1 acquire
> > + RELEASE 0x2 release
> > + ACQ_REL 0x3 acquire and release
> > + SEQ_CST 0x4 sequentially consistent
> > + ======= ===== =======================
>
> I understand that this is inspired by C,
> but what are the chances this will map meaningfully to hw?
> What JITs suppose to do with all other combinations ?
For context, those memorder flags were added after a discussion about
the SEQ_CST case on GitHub [1].
Do you anticipate we'll ever need BPF atomic seq_cst load/store
instructions?
If yes, I think we either:
(a) add more flags to imm<4-7>: maybe LOAD_SEQ_CST (0x3) and
STORE_SEQ_CST (0x6); need to skip OR (0x4) and AND (0x5) used by
RMW atomics
(b) specify memorder in imm<0-3>
I chose (b) for fewer "What would be a good numerical value so that RMW
atomics won't need to use it in imm<4-7>?" questions to answer.
If we're having dedicated fields for memorder, I think it's better to
define all possible values once and for all, just so that e.g. 0x2 will
always mean RELEASE in a memorder field. Initially I defined all six of
them [2], then Yonghong suggested dropping CONSUME [3].
[1] https://github.com/llvm/llvm-project/pull/108636#discussion_r1817555681
[2] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf#page=1817
[3] https://github.com/llvm/llvm-project/pull/108636#discussion_r1819380536
Thanks,
Peilin Ye
prev parent reply other threads:[~2025-01-30 7:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-25 2:16 [PATCH bpf-next v1 0/8] Introduce load-acquire and store-release BPF instructions Peilin Ye
2025-01-25 2:17 ` [PATCH bpf-next v1 1/8] bpf/verifier: Factor out atomic_ptr_type_ok() Peilin Ye
2025-01-25 2:18 ` [PATCH bpf-next v1 2/8] bpf/verifier: Factor out check_atomic_rmw() Peilin Ye
2025-01-25 2:18 ` [PATCH bpf-next v1 3/8] bpf: Introduce load-acquire and store-release instructions Peilin Ye
2025-01-29 0:19 ` Eduard Zingerman
2025-01-29 22:04 ` Peilin Ye
2025-01-29 22:42 ` Eduard Zingerman
2025-01-30 3:10 ` Peilin Ye
2025-01-29 1:30 ` Eduard Zingerman
2025-01-29 22:17 ` Peilin Ye
2025-01-30 0:41 ` Alexei Starovoitov
2025-01-30 3:38 ` Peilin Ye
2025-01-25 2:18 ` [PATCH bpf-next v1 4/8] arm64: insn: Add BIT(23) to {load,store}_ex's mask Peilin Ye
2025-01-25 2:19 ` [PATCH bpf-next v1 5/8] arm64: insn: Add load-acquire and store-release instructions Peilin Ye
2025-01-25 2:19 ` [PATCH bpf-next v1 6/8] bpf, arm64: Support " Peilin Ye
2025-01-25 2:19 ` [PATCH bpf-next v1 7/8] selftests/bpf: Add selftests for " Peilin Ye
2025-01-29 1:06 ` Eduard Zingerman
2025-01-29 2:07 ` Ihor Solodrai
2025-01-29 2:07 ` [Bpf] " Ihor Solodrai
2025-01-29 2:17 ` Eduard Zingerman
2025-01-30 0:03 ` Peilin Ye
2025-02-04 0:30 ` Peilin Ye
2025-02-04 0:52 ` Eduard Zingerman
2025-02-04 1:29 ` Peilin Ye
2025-01-25 2:19 ` [PATCH bpf-next v1 8/8] bpf, docs: Update instruction-set.rst " Peilin Ye
2025-01-30 0:44 ` Alexei Starovoitov
2025-01-30 7:33 ` Peilin Ye [this message]
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=Z5srM--fdH_JAgYT@google.com \
--to=yepeilin@google.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=brho@google.com \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=joshdon@google.com \
--cc=kpsingh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longyingchi24s@ict.ac.cn \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=neelnatu@google.com \
--cc=paulmck@kernel.org \
--cc=puranjay@kernel.org \
--cc=qmo@kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=void@manifault.com \
--cc=will@kernel.org \
--cc=xukuohai@huaweicloud.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.