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

Reply via email to