Re: [RFC PATCH tip 3/5] Extended BPF (64-bit BPF) design document

["H. Peter Anvin" <hpa@zytor.com>]

On 12/02/2013 08:28 PM, Alexei Starovoitov wrote:
> +
> +All BPF registers are 64-bit without subregs, which makes JITed x86 code
> +less optimal, but matches sparc/mips architectures.
> +Adding 32-bit subregs was considered, since JIT can map them to x86 and aarch64
> +nicely, but read-modify-write overhead for sparc/mips is not worth the gains.
> +

I find this tradeoff to be more than somewhat puzzling, given that x86
and ARM are by far the dominant tradeoffs, and it would make
implementation on 32-bit CPUs cheaper if a lot of the operations are 32 bit.

Instead it seems like the niche architectures (which, realistically,
SPARC and MIPS have become) ought to take the performance hit.

Perhaps you are simply misunderstanding the notion of subregisters.
Neither x86 nor ARM64 leave the top 32 bits intact, so I don't see why
SPARC/MIPS would do RMW either.

> +Q: Why extended BPF is 64-bit? Cannot we live with 32-bit?
> +A: On 64-bit architectures, pointers are 64-bit and we want to pass 64-bit
> +values in/out kernel functions, so 32-bit BPF registers would require to define
> +register-pair ABI, there won't be a direct BPF register to HW register
> +mapping and JIT would need to do combine/split/move operations for every
> +register in and out of the function, which is complex, bug prone and slow.
> +Another reason is counters. To use 64-bit counter BPF program would need to do
> +a complex math. Again bug prone and not atomic.

Having EBPF code manipulating pointers - or kernel memory - directly
seems like a nonstarter.  However, per your subsequent paragraph it
sounds like pointers are a special type at which point it shouldn't
matter at the EBPF level how many bytes it takes to represent it?

	-hpa