From owner-freebsd-net Thu May 3 9:12:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from dr-evil.shagadelic.org (yeah-baby.shagadelic.org [208.176.2.162]) by hub.freebsd.org (Postfix) with ESMTP id 0AF7837B423 for ; Thu, 3 May 2001 09:12:53 -0700 (PDT) (envelope-from thorpej@zembu.com) Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 1526F18B64; Thu, 3 May 2001 09:12:52 -0700 (PDT) Date: Thu, 3 May 2001 09:12:52 -0700 From: Jason R Thorpe To: Gunther Schadow Cc: Fulvio Risso , Luigi Rizzo , Darren Reed , snap-users@kame.net, julian@elischer.org, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: [altq 839] Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <20010503091252.F17582@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Gunther Schadow , Fulvio Risso , Luigi Rizzo , Darren Reed , snap-users@kame.net, julian@elischer.org, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp References: <200105030750.JAA44246@info.iet.unipi.it> <20010503083049.B17582@dr-evil.shagadelic.org> <3AF181E9.1B73B69E@aurora.regenstrief.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AF181E9.1B73B69E@aurora.regenstrief.org>; from gunther@aurora.regenstrief.org on Thu, May 03, 2001 at 04:06:01PM +0000 Organization: Zembu Labs, Inc. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, May 03, 2001 at 04:06:01PM +0000, Gunther Schadow wrote: > Hmm, so you are arguing gainst multiple return values and stateful > inspection? I like simplicity, but wouldn't this impede the ability > to produce high-performance classifiers? The approach I'm taking is to have the filters live in as large of a BPF program as possible (possibly multiple large BPF programs chained together by some glue). This allows the pcap code optimizer to do a better job. The pcap compiler is being modified to add a "return N" keyword, to instruct BPF to return a particular value. A combination of better optimizatoin and a generalized return statement allows you to do fast matching and fast dispatching. > What about adding a state memory to the BPF VM and allowing the BPF > VM to return an arbitrary long integer value. That value would index > the action to take for filters, mutators, encapsulators, forwarders > and queuers. You don't need to add anything to BPF itself to do this -- BPF can already return arbitrary values. The problem is the BPF instruction compiler that everyone uses (libpcap). -- -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message