Edward Cree <ec...@solarflare.com> wrote: > On 06/03/18 16:42, Florian Westphal wrote: > > I would also add 'highlevel' objects that are themselves translated into > > basic operations. Most obvious example > > are 'fetch 4 bytes x bytes into transport header'. > > > > Frontend should not need to bother with ipv4 details, such as ip > > options. Instead IMR should take care of this and generate the needed > > instructions to fetch iph->ihl and figure out the correct transport > > header offset. > Presumably then for this the IMR regs will cease to have any connection to > BPF regs and will simply be (SSA?) r0, r1, ... as far as needed (not > limited to 10 regs like BPF)? Then register allocation all happens in > the IMR->BPF conversion (even for things 64 bits or smaller). > > I wonder how sophisticated we should be about register allocation; whether > we should go the whole hog with graph-colouring algorithms or linear > scan, or just do something naïve like an LRU. > > Relatedly, should we spill values to the stack when we run out of > registers, or should we just rely on being able to rematerialise them > from parsing the packet again?
I don't know. I suspect we should go for naive algorithm only, but I would defer such decision to Alexei/Daniel. f.e. i don't know if using llvm is a good idea or not, I did not intend to turn proposed imr into full blown compiler in any case, I only want to avoid code duplication for iptables/nftables -> ebpf translator.
