On 04/14/2011 07:05 PM, Eric Dumazet wrote:

Le jeudi 14 avril 2011 à 18:53 +0300, Avi Kivity a écrit :

quoted

 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)

-- 
error compiling committee.c: too many arguments to function