IPFW update frequency

[Julian Elischer]

Freddie Cash wrote:
> On Friday 30 March 2007 01:40 pm, Julian Elischer wrote:
>> I have been looking at the IPFW code recently, especially
>> with respect to locking.
>> There are some things that could be done to improve IPFW's
>> behaviour when processing packets, but some of these take a
>> toll (there is always a toll) on the 'updating' side of things.
>>
>> For example. I can make IPFW lock-free during processing
>> of packets (i.e. not holding any locks while traversing the
>> list) which would solve problems we have with lock-order reversals
>> when it needs to look at the socket layer (which needs socket
>> layer locks). Unfortunatly this would make it a lot more expensive
>> in the case where new rules are being added to the list. possibly a LOT
>> more expensive. Now, this would only matter if one was adding (or
>> deleting) hundreds of rules per second to the firewall, but as I've
>> discovered, there's always SOMEONE that is doing the very thing you
>> imagine that no-one would ever do.
>>
>> In my imagination, most of the people who did this sort of thing don't
>> need to do it any more as tables obviate the need for that sort of
>> thing.
>>
>> Is there anyone out there who is adding hundreds (or even dozens) of
>> rules per second on a continuous basis, or who wants rule changing to
>> be a really efficient operation?
>> (does it matter to you if it takes a few milliSecs to add a rule?)
> 
> If the initial loading of a ruleset via a script counts, then yes.  We add 
> 600+ rules each time the script is run.  During testing, or when 
> troubleshooting connection issues, the rules could be reloaded several 
> times over 10 minutes.  We've moved away from adding rules dynamically, 
> preferring to add rules to the script and reload them all.  Keeps the 
> rules in memory in sync with the rules on disk.
> 
> Otherwise, no.  :)
> 

the new rules might take a second or two to load.. a load may take 
a couple of milliseconds vs less than that for now.