Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 May 2001 03:15:36 -0500
From:      Bill Fumerola <billf@mu.org>
To:        Luigi Rizzo <luigi@info.iet.unipi.it>
Cc:        Gunther Schadow <gunther@aurora.regenstrief.org>, Darren Reed <darrenr@reed.wattle.id.au>, thorpej@zembu.com, snap-users@kame.net, julian@elischer.org, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp
Subject:   Re: [altq 838] Re: The future of ALTQ, IPsec & IPFILTER playing together ...
Message-ID:  <20010503031536.H75584@elvis.mu.org>
In-Reply-To: <200105030750.JAA44246@info.iet.unipi.it>; from luigi@info.iet.unipi.it on Thu, May 03, 2001 at 09:50:25AM %2B0200
References:  <3AF108F2.BA4AF637@aurora.regenstrief.org> <200105030750.JAA44246@info.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 03, 2001 at 09:50:25AM +0200, Luigi Rizzo wrote:

> wrong. It is an interpreted bytecode, much slower than,
> say, approaches which translate individual filters into
> native machine code (DPT/DPF ? don't remember the exact reference,
> it was some usenix/sigcomm paper).

http://www.pdos.lcs.mit.edu/~engler/dpf.html

> >               and that BPF scales very well for even complex
> > expressions.
> 
> this is more a ruleset compiler issue, where you try to analyse
> the whole ruleset and find out what are the important
> field to look at, build a tree/trie to drive your
> searches, use lookup and hash tables, etc.e tc. -- there is a lot of
> recent literature on the topic of fast packet classification.

yeah, someone should write an ipfw compiler. :->

-- 
Bill Fumerola - security yahoo         / Yahoo! inc.
              - fumerola@yahoo-inc.com / billf@FreeBSD.org




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010503031536.H75584>