From owner-freebsd-net  Fri May  5  3:46: 6 2000
Delivered-To: freebsd-net@freebsd.org
Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2624837B613; Fri,  5 May 2000 03:45:47 -0700 (PDT)
	(envelope-from root@boostworks.com)
Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99])
	by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id MAA84336;
	Fri, 5 May 2000 12:44:19 +0200 (CEST)
Message-Id: <200005051044.MAA84336@luxren2.boostworks.com>
Date: Fri, 5 May 2000 12:44:31 +0200 (CEST)
From: Remy Nonnenmacher <remy@boostworks.com>
Reply-To: remy@boostworks.com
Subject: Re: ether matching in ipfw??
To: archie@whistle.com
Cc: rwatson@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
In-Reply-To: <200005021705.KAA02870@bubba.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On  2 May, Archie Cobbs wrote:
> Robert Watson writes:
>> One advantage to a BPF-like approach would be that you could imagine a
>> BPF->native code compiler, instead of a BPF execution vm in kernel, giving
>> performance close to ipfw, if not better, when optimized.  These custom
>> filtering modules built from userland rulesets could also be inserted
>> into the graph as needed.
> 
> See also..
> 
>   http://www.pdos.lcs.mit.edu/~engler/dpf.html
> 

This worth a reading. There is a possiblity to use it as an internal
switching engine to determine processing path. In this context, all
ipfw activities may be seen as added rules to a standard ruleset. The
interest of merging rules is that the switching code become a directly
executable one. Also, this may nicely merge the netgraph system and the
standard BSD networking one (DPF as the central hooking system for the
whole thing, like netgraph provides for netgraph's nodes).

RN.
IhM




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