Date: Sat, 31 Dec 2005 11:00:01 +0000 From: Darren Reed <darrenr@hub.freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw2.c Message-ID: <20051231110001.GA38051@hub.freebsd.org> In-Reply-To: <200512061045.jB6AjopR018089@repoman.freebsd.org> References: <200512061045.jB6AjopR018089@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 06, 2005 at 10:45:49AM +0000, Gleb Smirnoff wrote: > glebius 2005-12-06 10:45:49 UTC > > FreeBSD src repository > > Modified files: > sys/netinet ip_fw2.c > Log: > Optimize parallel processing of ipfw(4) rulesets eliminating the locking > of the radix lookup tables. Since several rnh_lookup() can run in > parallel on the same table, we can piggyback on the shared locking > provided by ipfw(4). While I understand what you're doing here, it isn't the correct way to approach this problem. The lock macros for locking the radix code are the ones that should be used here and are the ones that should be relied on to properly protect the data in the radix table, not ipfw locks. If someone were to now change the radix code in a way that depended upon the locking it currently has, ipfw would get broken needlessly. Whilst that kind of change isn't likely to happen, it would never happen if ipfw used the right locking interface for interaction with the radix code. Given you're using a r/w lock and the radix code uses a mutex (presumably put there by someone who studied this code?), how can you be sure the results of your change are safe ? Are you saying that the radix code can safely be wrapt up inside of a r/w lock instead of a mutex ? Why not change the LOCK macros for radix.[ch] if that is the case ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051231110001.GA38051>