On Tue, Aug 1, 2023 at 7:34 PM Watson Ladd <watsonbladd@xxxxxxxxx> wrote: > > In reply to a long conversation: > <snip> > > > > Could you please be specific which instruction in table 4 is not obvious? > > The question isn't obvious, the question is unambigious, and C is not > great for this. Maybe with a reference and some text it would get > better. > > > > > > > > > > > > The good news is I think this is very fixable although tedious. > > > > > > > > > > > > The other thornier issues are memory model etc. But the overall structure seems good > > > > > > and the document overall makes sense. > > > > > > > > What do you mean by "memory model" ? > > > > Do you see a reference to it ? Please be specific. > > > > > > No, and that's the problem. Section 5.2 talks about atomic operations. > > > I'd expect that to be paired with a description of barriers so that > > > these work, or a big warning about when you need to use them. > > > > That's a good suggestion. > > A warning paragraph that BPF ISA does not have barrier instructions > > is necessary. > > > > > For > > > clarity I'm pretty unfamiliar with bpf as a technology, and it's > > > possible that with more knowledge this would make sense. On looking > > > back on that I don't even know if the memory space is flat, or > > > segmented: can I access maps through a value set to dst+offset, or > > > must I always used index? I'm just very confused. > > > > flat vs segmented is an orthogonal topic. > > We definitely need to cover it in the architecture doc. > > BPF WG charter requires us to produce it as Informational doc eventually. > > Huh? If you access memory through specialized descriptors+offsets > that's very different from arbitrary computations with addresses, even > if they do trap. A little explanation might orient the reader to > understand what is going on. As is I thought "ok, it's flat" and then > saw the maps and really got thrown for a loop. It's flat. > > > > As far as memory model BPF adopts LKMM (Linux Kernel Memory Model). > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html > > > > We can add a reference to it from BPF ISA doc, but since > > there are no barrier instructions at the moment the memory model > > statement would be premature. > > The work on "BPF Memory Model" have been ongoing for quite some time. > > For example see: > > https://lpc.events/event/11/contributions/941/attachments/859/1667/bpf-memory-model.2020.09.22a.pdf > > > > BPF Memory Model is certainly an important topic, but out of scope for ISA. > > I expect that an ISA defines the semantics of the instructions. Which > absolutely includes the memory model. Now maybe we're envisioning a > different splitting of this information, but I don't see how it can't > be at a different level if you want to give the instructions > semantics. Please read the links above. BPF ISA is not going to define TSO, dictate weak ordering or anything like that. It follows Linux Kernel Memory Model which is closer to C memory model than to what HW CPUs see as memory model. It's unlikely that we will ever introduce explicit memory barrier instructions. More likely they will be kfuncs that will map to smp_mb(), dma_wmb(), and friends in kernel Documentation/memory-barriers.txt. Analogies with HW ISAs are not applicable here.
