From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 30 23:57:15 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 451A416A402 for ; Fri, 30 Mar 2007 23:57:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outJ.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id 3494813C489 for ; Fri, 30 Mar 2007 23:57:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 30 Mar 2007 16:16:17 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 911D0125D56; Fri, 30 Mar 2007 16:45:32 -0700 (PDT) Message-ID: <460DA11B.9060401@elischer.org> Date: Fri, 30 Mar 2007 16:45:31 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Freddie Cash References: <460D75CE.70804@elischer.org> <200703301421.29919.fcash@ocis.net> In-Reply-To: <200703301421.29919.fcash@ocis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW update frequency X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 23:57:15 -0000 Freddie Cash wrote: > On Friday 30 March 2007 01:40 pm, Julian Elischer wrote: >> I have been looking at the IPFW code recently, especially >> with respect to locking. >> There are some things that could be done to improve IPFW's >> behaviour when processing packets, but some of these take a >> toll (there is always a toll) on the 'updating' side of things. >> >> For example. I can make IPFW lock-free during processing >> of packets (i.e. not holding any locks while traversing the >> list) which would solve problems we have with lock-order reversals >> when it needs to look at the socket layer (which needs socket >> layer locks). Unfortunatly this would make it a lot more expensive >> in the case where new rules are being added to the list. possibly a LOT >> more expensive. Now, this would only matter if one was adding (or >> deleting) hundreds of rules per second to the firewall, but as I've >> discovered, there's always SOMEONE that is doing the very thing you >> imagine that no-one would ever do. >> >> In my imagination, most of the people who did this sort of thing don't >> need to do it any more as tables obviate the need for that sort of >> thing. >> >> Is there anyone out there who is adding hundreds (or even dozens) of >> rules per second on a continuous basis, or who wants rule changing to >> be a really efficient operation? >> (does it matter to you if it takes a few milliSecs to add a rule?) > > If the initial loading of a ruleset via a script counts, then yes. We add > 600+ rules each time the script is run. During testing, or when > troubleshooting connection issues, the rules could be reloaded several > times over 10 minutes. We've moved away from adding rules dynamically, > preferring to add rules to the script and reload them all. Keeps the > rules in memory in sync with the rules on disk. > > Otherwise, no. :) > the new rules might take a second or two to load.. a load may take a couple of milliseconds vs less than that for now.