Re: [PATCH bpf-next v1 8/8] bpf, docs: Update instruction-set.rst for load-acquire and store-release instructions

From: Peilin Ye
Date: Thu Jan 30 2025 - 02:33:23 EST


+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@xxxxxxxxxx> 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