From owner-freebsd-net Thu May 3 1:16:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from menelao.polito.it (menelao.polito.it [130.192.3.30]) by hub.freebsd.org (Postfix) with SMTP id EB13D37B43C for ; Thu, 3 May 2001 01:16:39 -0700 (PDT) (envelope-from risso@polito.it) Received: (qmail 28075 invoked from network); 3 May 2001 08:16:36 -0000 Received: from truciolo.polito.it (HELO truciolo) (130.192.16.81) by menelao.polito.it with SMTP; 3 May 2001 08:16:36 -0000 From: "Fulvio Risso" To: "Luigi Rizzo" , "Gunther Schadow" Cc: "Darren Reed" , , , , , , Subject: RE: [altq 839] Re: The future of ALTQ, IPsec & IPFILTER playing together ... Date: Thu, 3 May 2001 10:15:36 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200105030750.JAA44246@info.iet.unipi.it> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > -----Original Message----- > From: owner-altq@csl.sony.co.jp [mailto:owner-altq@csl.sony.co.jp]On > Behalf Of Luigi Rizzo > Sent: Thursday, May 03, 2001 09:50 > To: Gunther Schadow > Cc: Darren Reed; 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: [altq 839] Re: The future of ALTQ, IPsec & IPFILTER playing > together ... > > > > 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). BPF+ has a JIT. We made several tests with an experimental version of a JIT for Win32 and we were able to improve speed by a factor 10. If I remeber well, this is the same result of BPF+ people. However a JIT for BPF is *really* very simple ==> BPF could be seen as really fast packet filter. (by the way, we should include a JIT in our future releases of WinPcap). > > and that BPF scales very well for even complex > > expressions. > > this is more a ruleset compiler issue, where you try to analyse Not only. BPF does not support: - stateful inspection - multiple return values (only 1/0) - multiple outputs (I want to know, for example the amount of traffic IP *and* TCP) Even a really good compiler cannot avoid these problems. ==> BPF is fast; it is not powerful enough for other apps but capturing packets. Cheers, fulvio > 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