[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1302795630.3248.10.camel@edumazet-laptop>
Date: Thu, 14 Apr 2011 17:40:30 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Avi Kivity <avi@...hat.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Ben Hutchings <bhutchings@...arflare.com>,
Hagen Paul Pfeifer <hagen@...u.net>
Subject: Re: [PATCH v2] net: filter: Just In Time compiler
Le jeudi 14 avril 2011 à 17:40 +0300, Avi Kivity a écrit :
> On 04/03/2011 04:56 PM, Eric Dumazet wrote:
> > In order to speedup packet filtering, here is an implementation of a JIT
> > compiler for x86_64
> >
>
> Have you considered putting the compiler in userspace?
>
Hmm, to be honest no.
> You could have a trusted compile server waiting on a pipe and compiling
> programs sent to it by the kernel, sending the results back down. Use
> the interpreter until the compiler returns; if it doesn't, use the
> interpreter forever.
I feel it might be too expensive in some cases, and kind of complex
architecture.
>
> The upside is that you can use established optimizing compilers like
> LLVM or GCC, which already support more target architectures. It may
> not matter much for something simple like bpf, but other VMs may be a
> lot more complicated.
>
Not only bpf is very simple, but it needs to access skb fields and other
parts of the kernel, we would need to instruct userland compiler of all
these details.
We would need to load kind of a module (with dynamic loader)
Of course, making each bpf filter a module of his own has benefit for
perf profiling.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists