From owner-freebsd-net@FreeBSD.ORG Mon Nov 28 10:38:35 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 1430616A420 for ; Mon, 28 Nov 2005 10:38:35 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1FFF43D5E for ; Mon, 28 Nov 2005 10:38:32 +0000 (GMT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 5191 invoked from network); 28 Nov 2005 10:38:30 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 28 Nov 2005 10:38:30 -0000 Received: (nullmailer pid 16076 invoked by uid 136); Mon, 28 Nov 2005 10:42:41 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20051128094727.GK25711@cell.sick.ru> To: Gleb Smirnoff Date: Mon, 28 Nov 2005 13:42:41 +0300 (MSK) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1133174561.369095.16075.nullmailer@cicuta.babolo.ru> Cc: Vsevolod Lobko , rwatson@FreeBSD.org, Ruslan Ermilov , 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: Mon, 28 Nov 2005 10:38:35 -0000 > On Mon, Nov 28, 2005 at 08:27:32AM +0200, Ruslan Ermilov wrote: > R> > Can you try my patch? Since it reduces the total number of mutex > R> > operations it should be a win on UP, too. > R> We're currently based on 4.x. You can try it yourself: create > R> a table with 10000 entries and with value 13. Then write a > R> ruleset with 13 rules that look up this table so that the last > R> rule looks it up with value 13, and do a benchmark. Let me > R> know what are results with and without caching. > Such kind of firewall looks like unoptimized. Why should we optimize the > code for non-optimized setups. Can't we avoid looking into one table > 13 times each packet? add 47400 pipe 47400 ip from table(0, 0) to any add 47401 pipe 47401 ip from table(0, 1) to any add 47402 pipe 47402 ip from table(0, 2) to any add 47403 pipe 47403 ip from table(0, 3) to any add 47404 pipe 47404 ip from table(0, 4) to any add 47405 pipe 47405 ip from table(0, 5) to any add 47406 pipe 47406 ip from table(0, 6) to any add 47407 pipe 47407 ip from table(0, 7) to any add 47408 pipe 47408 ip from table(0, 8) to any add 47409 pipe 47409 ip from table(0, 9) to any for different traffic consumers listed in table(0)