From owner-freebsd-net@FreeBSD.ORG Tue Nov 29 15:36:16 2005 Return-Path: X-Original-To: freebsd-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 2634616A420 for ; Tue, 29 Nov 2005 15:36:16 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D240243D5C for ; Tue, 29 Nov 2005 15:36:14 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 51404 invoked from network); 29 Nov 2005 15:34:11 -0000 Received: from c00l3r.networx.ch (HELO networx.ch) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2005 15:34:11 -0000 Message-ID: <438C7561.41E09BBD@networx.ch> Date: Tue, 29 Nov 2005 16:36:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20051127005943.GR25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> <200511281805.11952.max@love2party.net> <20051128191751.GZ25711@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Max Laier , Ruslan Ermilov , rwatson@FreeBSD.org, Vsevolod Lobko , freebsd-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: Tue, 29 Nov 2005 15:36:16 -0000 Gleb Smirnoff wrote: > On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote: > M> I remember that we had an extensive discussion about this around > M> FreeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or > M> cacheing. Stack storage should work as well. > > The cacheing is a good idea when one table is looked up several times > for one packet. The above proposal eliminates need for such rulesets. > And thus we can work towards parallelizm. The ipfw tables are protected by the ipfw lock. So this parallel lookup Gelb has in his patch works fine and doesn't have any races. No caching between packets can be done without extra locks. Only caching between rules can be done by saving the result on the stack. The result must not be accessed anymore once the ipfw lock has been given up. -- Andre