Re: [PATCH v2] net: filter: Just In Time compiler

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mercredi 20 avril 2011 à 10:41 +0300, Avi Kivity a écrit :
> On 04/14/2011 07:05 PM, Eric Dumazet wrote:
> > Le jeudi 14 avril 2011 à 18:53 +0300, Avi Kivity a écrit :
> >
> > >  IMO, it will.  I'll try to have gcc optimize your example filter later.
> >
> > Sure you can JIT a C program from bpf. It should take maybe 30 minutes.
> > It certainly is more easy than JIT an binary/assembly code :)
> >
> > Now take a look how I call slowpath, I am not sure gcc will actually
> > generate better code because of C conventions.
> 
> Some things will be the same (like calling a function outside the jit).  
> Some things will be faster.
> 
> > Loading a filter should be fast.
> > Invoking a compiler is just too much work for BPF.
> > Remember loading a filter is available to any user.
> 
> Like I mentioned before, use the interpreter until the result of the 
> jitter is available.
> 
> > This idea would be good for netfilter stuff, because we dont load
> > iptables rules that often.
> >
> > But still, the netfilter mainloop can be converted as a kernel JIT, most
> > probably. All the complex stuff (matches, targets) must call external
> > procedures anyway.
> 
> We could convert some matches to bytecode, probably.
> 
> To avoid getting into an infinite loop (btw, does you jit avoid infinite 
> loops in the generated code?) I'll restate what I think are an external 
> jit's advantages and then stop harping on the subject:
> 
> - less effort
> - less kernel code
> - better arch support
> - better optimization
> - better profiler/debugger integration
> - multiple optimization levels (can use your jitter in userspace, or 
> gcc, or llvm)
> 

No problem, I'll wait your work on this then.

I disagree having a gcc on production machines, I'm not sure it will
please admins...

Thanks