[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1291227893.2856.1039.camel@edumazet-laptop>
Date: Wed, 01 Dec 2010 19:24:53 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: David Miller <davem@...emloft.net>
Cc: hagen@...u.net, xiaosuo@...il.com, wirelesser@...il.com,
netdev@...r.kernel.org
Subject: Re: multi bpf filter will impact performance?
Le mercredi 01 décembre 2010 à 10:18 -0800, David Miller a écrit :
> From: Hagen Paul Pfeifer <hagen@...u.net>
> Date: Wed, 01 Dec 2010 18:22:48 +0100
>
> > On Wed, 01 Dec 2010 09:42:47 +0100, Eric Dumazet wrote:
> >
> >> IMHO, a better pcap optimizer would be the first step.
> >
> > +1
> >
> > Optimizing complex filter rules is step one in the process of optimizing
> > the packet processing. A JIT compiler like FreeBSD provides cannot polish a
> > (pcap)turd. I thought Patrick was working on a generic filter mechanism for
> > netfilter!? ... ;)
>
> Yes, and we spoke at the netfilter workshop about making that interpreter
> available to socket filters and the packet classifier layer.
>
> However, I think it's still valuable to write a few JIT compilers for
> the existing BPF stuff. I considered working on a sparc64 JIT just to
> see what it would look like.
>
> If people work on the BPF optimizer and BPF JITs in parallel, we'll have
> both ready at the same time. win++
A third work in progress (from my side) is to add a check in
sk_chk_filter() to remove the memvalid we added lately to protect the
LOAD M(K).
It is needed anyway for arches without a BPF JIT :)
--
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