Date: Mon, 16 Jan 2006 12:39:45 +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: <20060116123945.GA49077@hub.freebsd.org> In-Reply-To: <200601150055.k0F0t52R028617@repoman.freebsd.org> References: <200601150055.k0F0t52R028617@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 15, 2006 at 12:55:05AM +0000, Gleb Smirnoff wrote: > glebius 2006-01-15 00:55:05 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_6) > sys/netinet ip_fw2.c > Log: > MFC 1.118: > 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). > However, the single entry cache in the ip_fw_table can't be used lockless, > so it is removed. This pessimizes two cases: processing of bursts of similar > packets and matching one packet against the same table several times during > one ipfw_chk() lookup. To optimize the processing of similar packet bursts > administrator should use stateful firewall. To optimize the second problem > a solution will be provided soon. I'll mention this again...this is bad programming for the kernel. While it works, it is incorrect because it doesn't use the locking primitives that have been written for the radix tree. This is hack work - there is nothing clever or good about it. If there is a concern about locking around the radix tree impacting performance then the correct thing to do is fix that, not to throw away what exists today and use your own. In that way routing would also benefit from the change, not just ipfw. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060116123945.GA49077>