Date: Wed, 18 Apr 2007 16:10:36 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Julian Elischer <julian@elischer.org> Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. Message-ID: <20070418161036.A21780@xorpc.icir.org> In-Reply-To: <4626932B.20505@elischer.org>; from julian@elischer.org on Wed, Apr 18, 2007 at 02:52:43PM -0700 References: <46268689.1080301@elischer.org> <B0E21175-5606-4DAB-9810-BA8F162BE17B@mac.com> <4626932B.20505@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 18, 2007 at 02:52:43PM -0700, Julian Elischer wrote: > Chuck Swiger wrote: > > On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: > >> I'm contemplating the following changes to functionality: > >> I'd like suggestions and comments... > >> > >> 1/ Commit capability > >> In this change you declare a new firewall, > >> and modify/build it, and then you 'commit' it so that > >> the whole change is atomic. > > [ ... ] ... > I'll try express it better again in a second... > > ipfw sets are curently impemented by adding a set number to each rule. > By enabling and disabling the sets one controls which rules are skipped over, > however they are still all in the same linked list of rules. > If you have a set of 1000 rules and disable 999 of them, the packet still > has to follow 1000 links. if what you want is just optimising the walk through rules, you could do just that, i.e. add a 'the_real_next_rule' field which gets reset when a significant change occurs (e.g. enable/disable a set, or add/delete a rule) and initialized lazily the first time it needs to be dereferenced. This is the same thing that ipfw does for skipto targets, so the mechanism is already in place somehow. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070418161036.A21780>