Date: Sun, 27 Nov 2005 22:59:14 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: Vsevolod Lobko <seva@ip.net.ua>, rwatson@FreeBSD.org, net@FreeBSD.org Subject: Re: parallelizing ipfw table Message-ID: <20051127195914.GI25711@cell.sick.ru> In-Reply-To: <20051127194545.GA76200@ip.net.ua> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051127195914.GI25711>