Date: Sun, 1 Apr 2007 13:19:18 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, ipfw@freebsd.org Subject: Re: IPFW update frequency Message-ID: <20070401131715.H1185@fledge.watson.org> In-Reply-To: <460D75CE.70804@elischer.org> References: <460D75CE.70804@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 30 Mar 2007, 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?) Just to make sure this hits the public thread also, as I know we've talked about it privately: Stephan Upholf has an implementation of a mostly-read lock in the works, which avoids any atomic operations during acquisition of a read reference, at the cost of increasing the cost of write lock acquires. This might provide what we need without fundamentally restructuring ipfw. It would be useful, once that is available, to examine the costs and benefits of both approaches side-by-side. Historically, I've been quite interested in doing something like that you describe, but the complexity cost is high, so if we can make a simpler solution (mrlocks) work just as well, that would be preferable. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070401131715.H1185>