Date: Thu, 3 May 2001 09:50:25 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Gunther Schadow <gunther@aurora.regenstrief.org> Cc: 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: <200105030750.JAA44246@info.iet.unipi.it> In-Reply-To: <3AF108F2.BA4AF637@aurora.regenstrief.org> from Gunther Schadow at "May 3, 2001 07:29:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> is fast, as fast as it gets. It is my understanding that BPF > is very fast 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). > 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. cheers luigi > would want a number representing the class. Also, it's beenong > noted before, the BPF machine needs some state awareness between > packets. > > regards > -Gunther > > -- > Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org > Medical Information Scientist Regenstrief Institute for Health Care > Adjunct Assistent Professor Indiana University School of Medicine > tel:1(317)630-7960 http://aurora.regenstrief.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?200105030750.JAA44246>