ipfw changes being contemplated..

Julian Elischer julian at elischer.org
Thu Apr 19 00:31:36 UTC 2007


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



More information about the freebsd-ipfw mailing list