On Fri, Mar 29, 2024 at 4:47 PM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Fri, Mar 29, 2024 at 11:47 AM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote:
> >
> > Add two new BPF instructions for dealing with per-CPU memory.
> >
> > One, BPF_LDX | BPF_ADDR_PERCPU | BPF_DW (where BPF_ADD_PERCPU is unused
> > 0xe0 opcode),
>
> ADD or ADDR ?
>
ADDR, typo
> > I also added BPF_LDX | BPF_MEM_PERCPU | BPF_{B,H,W,DW} (BPF_MEM_PERCPU using
> > another unused 0xc0 opcode), which can be considered an optimization
> > instruction, which allows to *read* per-CPU data up to 8 bytes in one
> > instruction, without having to first resolve the address and then
> > dereferencing the memory. This one is used in inlining of
> > bpf_get_smp_processor_id(), but it would be fine to implement the latter with
> > BPF_ADD_PERCPU, followed by normal BPF_LDX | BPF_MEM, so I'm fine dropping
>
> ADD or ADDR ?
> Looking at the rest is probably ADDR.
Yep, it's all ADDR.
>
> Feels weird for BPF_LDX to mean dst = src + percpu_off.
> Should it be on BPF_ALU64 side? Like a flavor of BPF_MOV ?
Yeah, it felt a bit out of place. I started with BPF_MEM_PERCPU, which
was true load instruction, then realized I need per-cpu address
instruction, so I just kept them close to each other. I'll look at
BPF_MOV flavor based on off.
Would you like to keep BPF_MEM_PERCPU in addition to BPF_ADDR_PERCPU?
Or should I drop it?
> We have several of such flavors:
> off = 1 -> arena
> off = 8, 16, 32 - swaps
> off = 2 - might be nop_of_goto
