Date: Wed, 18 Apr 2007 17:29:11 -0700 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. Message-ID: <4626B7D7.3060207@elischer.org> In-Reply-To: <20070418161036.A21780@xorpc.icir.org> References: <46268689.1080301@elischer.org> <B0E21175-5606-4DAB-9810-BA8F162BE17B@mac.com> <4626932B.20505@elischer.org> <20070418161036.A21780@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > 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. it is but it doesn't really give me what I want with "efficient computed skipto" I think I'll firm up my proposal a bit before trying to explain too much more, but if I have tow versions of the ruleset.. one a linked list that I can edit easily, and one "compiled" version that is run, then I can put the compiled version int an array and do binary searching to get quickly to a random rule number instead of traversing a possibly long linked list. I can also do some interesting tricks with reference counts on the array, to ensure that I don't hold any lock when traversing the firewall, which allows me to bypass all the problems I am currently seeing with Lock-order-reversals. Iplan on still having the cached hints but that won't work for "skipto tablearg ip from me to any" as 'tablearg' could be anything. > > cheers > luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4626B7D7.3060207>