On Wed, Jan 30, 2019 at 06:11:00PM +0000, Will Deacon wrote: > Assuming that a desirable property of an eBPF program is portability between > CPU architectures, then you're effectively forcing the programmer to "assume
that is fundamental misunderstanding that being thrown in this thread. bpf is not fixated on portability. All projects that tried to come up with universal byte code miserably failed. bpf program compiled for big endian won't load on little. bpf program designed to be used on x86 will work horribly slow on nfp. It will work, but will be innefficient. Hence we have alu32 mode in llvm. More so maps don't map one to one to all archs either. per-cpu map doesn't exist on nfp. we're still figuring out an equivalent for it for nfp. So, no, programs are not portable across architectures. The programmer cannot assume that. They could be portable in some cases and we're trying to keep portability as much as possible, but it's not a "desirable property" that we're going to sacrifice performance and usability for it. If it helps look at bpf as a safe kernel module. Does given kernel module work on all archs? No. Sometimes users only need to recompile it and sometimes do heavy changes. smp_mb and load acquire are the list things to worry about when folks trying to make such 'safe kernel module' work on different archs.
