[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQ+hi3918DUyA7bs4Va9NdNqXJg-R4A45n_MHGTikYaOSA@mail.gmail.com>
Date: Wed, 29 Jan 2025 16:44:02 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Peilin Ye <yepeilin@...gle.com>
Cc: bpf <bpf@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, bpf@...f.org,
Xu Kuohai <xukuohai@...weicloud.com>, Eduard Zingerman <eddyz87@...il.com>,
David Vernet <void@...ifault.com>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
Jiri Olsa <jolsa@...nel.org>, Jonathan Corbet <corbet@....net>,
"Paul E. McKenney" <paulmck@...nel.org>, Puranjay Mohan <puranjay@...nel.org>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Quentin Monnet <qmo@...nel.org>, Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>,
Josh Don <joshdon@...gle.com>, Barret Rhoden <brho@...gle.com>, Neel Natu <neelnatu@...gle.com>,
Benjamin Segall <bsegall@...gle.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v1 8/8] bpf, docs: Update instruction-set.rst for
load-acquire and store-release instructions
On Fri, Jan 24, 2025 at 6:19 PM Peilin Ye <yepeilin@...gle.com> wrote:
>
> Update documentation for the new load-acquire and store-release
> instructions. Rename existing atomic operations as "atomic
> read-modify-write (RMW) operations".
>
> Following RFC 9669, section 7.3. "Adding Instructions", create new
> conformance groups "atomic32v2" and "atomic64v2", where:
>
> * atomic32v2: includes all instructions in "atomic32", plus the new
> 8-bit, 16-bit and 32-bit atomic load-acquire and
> store-release instructions
>
> * atomic64v2: includes all instructions in "atomic64" and
> "atomic32v2", plus the new 64-bit atomic load-acquire
> and store-release instructions
>
> Cc: bpf@...f.org
> Signed-off-by: Peilin Ye <yepeilin@...gle.com>
> ---
> .../bpf/standardization/instruction-set.rst | 114 +++++++++++++++---
> 1 file changed, 98 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst
> index ab820d565052..86917932e9ef 100644
> --- a/Documentation/bpf/standardization/instruction-set.rst
> +++ b/Documentation/bpf/standardization/instruction-set.rst
> @@ -139,8 +139,14 @@ This document defines the following conformance groups:
> specification unless otherwise noted.
> * base64: includes base32, plus instructions explicitly noted
> as being in the base64 conformance group.
> -* atomic32: includes 32-bit atomic operation instructions (see `Atomic operations`_).
> -* atomic64: includes atomic32, plus 64-bit atomic operation instructions.
> +* atomic32: includes 32-bit atomic read-modify-write instructions (see
> + `Atomic operations`_).
> +* atomic32v2: includes atomic32, plus 8-bit, 16-bit and 32-bit atomic
> + load-acquire and store-release instructions.
> +* atomic64: includes atomic32, plus 64-bit atomic read-modify-write
> + instructions.
> +* atomic64v2: unifies atomic32v2 and atomic64, plus 64-bit atomic load-acquire
> + and store-release instructions.
> * divmul32: includes 32-bit division, multiplication, and modulo instructions.
> * divmul64: includes divmul32, plus 64-bit division, multiplication,
> and modulo instructions.
> @@ -653,20 +659,31 @@ Atomic operations are operations that operate on memory and can not be
> interrupted or corrupted by other access to the same memory region
> by other BPF programs or means outside of this specification.
>
> -All atomic operations supported by BPF are encoded as store operations
> -that use the ``ATOMIC`` mode modifier as follows:
> +All atomic operations supported by BPF are encoded as ``STX`` instructions
> +that use the ``ATOMIC`` mode modifier, with the 'imm' field encoding the
> +actual atomic operation. These operations are categorized based on the second
> +lowest nibble (bits 4-7) of the 'imm' field:
>
> -* ``{ATOMIC, W, STX}`` for 32-bit operations, which are
> +* ``ATOMIC_LOAD`` and ``ATOMIC_STORE`` indicate atomic load and store
> + operations, respectively (see `Atomic load and store operations`_).
> +* All other defined values indicate an atomic read-modify-write operation, as
> + described in the following section.
> +
> +Atomic read-modify-write operations
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The atomic read-modify-write (RMW) operations are encoded as follows:
> +
> +* ``{ATOMIC, W, STX}`` for 32-bit RMW operations, which are
> part of the "atomic32" conformance group.
> -* ``{ATOMIC, DW, STX}`` for 64-bit operations, which are
> +* ``{ATOMIC, DW, STX}`` for 64-bit RMW operations, which are
> part of the "atomic64" conformance group.
> -* 8-bit and 16-bit wide atomic operations are not supported.
> +* 8-bit and 16-bit wide atomic RMW operations are not supported.
>
> -The 'imm' field is used to encode the actual atomic operation.
> -Simple atomic operation use a subset of the values defined to encode
> -arithmetic operations in the 'imm' field to encode the atomic operation:
> +Simple atomic RMW operation use a subset of the values defined to encode
> +arithmetic operations in the 'imm' field to encode the atomic RMW operation:
>
> -.. table:: Simple atomic operations
> +.. table:: Simple atomic read-modify-write operations
>
> ======== ===== ===========
> imm value description
> @@ -686,10 +703,10 @@ arithmetic operations in the 'imm' field to encode the atomic operation:
>
> *(u64 *)(dst + offset) += src
>
> -In addition to the simple atomic operations, there also is a modifier and
> -two complex atomic operations:
> +In addition to the simple atomic RMW operations, there also is a modifier and
> +two complex atomic RMW operations:
>
> -.. table:: Complex atomic operations
> +.. table:: Complex atomic read-modify-write operations
>
> =========== ================ ===========================
> imm value description
> @@ -699,8 +716,8 @@ two complex atomic operations:
> CMPXCHG 0xf0 | FETCH atomic compare and exchange
> =========== ================ ===========================
>
> -The ``FETCH`` modifier is optional for simple atomic operations, and
> -always set for the complex atomic operations. If the ``FETCH`` flag
> +The ``FETCH`` modifier is optional for simple atomic RMW operations, and
> +always set for the complex atomic RMW operations. If the ``FETCH`` flag
> is set, then the operation also overwrites ``src`` with the value that
> was in memory before it was modified.
>
> @@ -713,6 +730,71 @@ The ``CMPXCHG`` operation atomically compares the value addressed by
> value that was at ``dst + offset`` before the operation is zero-extended
> and loaded back to ``R0``.
>
> +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 ?
> +Currently the following combinations of ``type`` and ``order`` are allowed:
> +
> +.. table:: Atomic load and store operations
> +
> + ========= ===== ====================
> + imm value description
> + ========= ===== ====================
> + LOAD_ACQ 0x11 atomic load-acquire
> + STORE_REL 0x22 atomic store-release
> + ========= ===== ====================
Should we do LOAD_ACQ=1 and STORE_REL=2 and
do not add anything else?
Powered by blists - more mailing lists