From owner-cvs-src@FreeBSD.ORG Mon Jan 16 12:39:45 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 680) id E1E7116A420; Mon, 16 Jan 2006 12:39:45 +0000 (GMT) Date: Mon, 16 Jan 2006 12:39:45 +0000 From: Darren Reed To: Gleb Smirnoff Message-ID: <20060116123945.GA49077@hub.freebsd.org> References: <200601150055.k0F0t52R028617@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601150055.k0F0t52R028617@repoman.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fw2.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2006 12:39:46 -0000 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