From owner-cvs-src@FreeBSD.ORG Mon Jan 16 12:47:18 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73E4216A41F; Mon, 16 Jan 2006 12:47:18 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D2D543D5C; Mon, 16 Jan 2006 12:47:17 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id k0GClECX036380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2006 15:47:15 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id k0GClE4g036379; Mon, 16 Jan 2006 15:47:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 16 Jan 2006 15:47:14 +0300 From: Gleb Smirnoff To: Darren Reed Message-ID: <20060116124714.GZ83922@FreeBSD.org> References: <200601150055.k0F0t52R028617@repoman.freebsd.org> <20060116123945.GA49077@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060116123945.GA49077@hub.freebsd.org> User-Agent: Mutt/1.5.6i 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:47:18 -0000 On Mon, Jan 16, 2006 at 12:39:45PM +0000, Darren Reed wrote: D> I'll mention this again...this is bad programming for the kernel. D> D> While it works, it is incorrect because it doesn't use the locking D> primitives that have been written for the radix tree. D> D> This is hack work - there is nothing clever or good about it. D> D> If there is a concern about locking around the radix tree impacting D> performance then the correct thing to do is fix that, not to throw D> away what exists today and use your own. In that way routing would D> also benefit from the change, not just ipfw. There is no law to use locking in some subsystem, if the caller can provide the safe access himself. Radix doesn't have any locking in it. Radix is known to be not modified by lookups. This means, that we can do lookups lockless, if we have a guarantee that table won't be modified. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE