From owner-freebsd-net@FreeBSD.ORG Sun Nov 27 19:59:18 2005 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E19D16A41F; Sun, 27 Nov 2005 19:59: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 6C3D243D66; Sun, 27 Nov 2005 19:59: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 jARJxEgB086607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Nov 2005 22:59:15 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jARJxEOl086606; Sun, 27 Nov 2005 22:59:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 27 Nov 2005 22:59:14 +0300 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20051127195914.GI25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051127194545.GA76200@ip.net.ua> User-Agent: Mutt/1.5.6i Cc: Vsevolod Lobko , rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 19:59:18 -0000 Ruslan, On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote: R> Nope, I need this caching. It's for looking up the same table R> several times in a row but with various values. For example, R> we use ipfw tables to route the traffic to the correct dummynet R> pipe, where value is the bandwidth, and this caching helps a lot. Have you benchmarked that this caching is important? On a router that serves a lot of parallel traffic flows the caching is not a benefit, but additional processing. I think we should optimize the code for more loaded environments, since we don't care about CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%. In general such kind of caching in network code is an old fashion, that causes a problems when we attempt to make code more parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201 and we will soon remove route caching in gif(4), because it causes problems on SMP. Can you try my patch? Since it reduces the total number of mutex operations it should be a win on UP, too. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE