Date: Fri, 30 Mar 2007 16:50:48 -0700 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@icir.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, ipfw@freebsd.org Subject: Re: IPFW update frequency Message-ID: <460DA258.2030402@elischer.org> In-Reply-To: <20070330145938.A88154@xorpc.icir.org> References: <460D75CE.70804@elischer.org> <20070330145938.A88154@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > On Fri, Mar 30, 2007 at 01:40:46PM -0700, 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. > > certainly ipfw was not designed with SMP in mind. > If you can tell us what is your plan to make the list lock free > (which one, the static or dynamic ones ?) maybe we can comment more. > > E.g. one option could be the usual trick of adding refcounts to > the individual rules, and then using an array of pointers to them. > While processing you grab a refcount to the array, and release it once > done with the packet. If there is an addition or removal, you duplicate > the array (which may be expensive for the large 20k rules mentioned), > manipulate the copy and then atomically swap the pointers to the head. This is pretty close.. I know I've mentioned this to people several times over the last year or so. the trick is to try do it in a way that the average packet doesn't need to do any locks to get in and the updater does more work. if you are willing to acquire a lock on both starting and ending the run through the firewall it is easy. (I already have code to do that..) (see http://www.freebsd.org/~julian/atomic_replace.c (untested but probably close.) doing it without requiring that each packet get those locks however is a whole new level of problem. > > This might even work for dynamic rules as the lists (the content of > each hash bucket) are typically short. yep > > cheers > luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?460DA258.2030402>