From owner-freebsd-ipfw@FreeBSD.ORG Thu Apr 19 00:31:36 2007 Return-Path: X-Original-To: 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 66D1A16A406 for ; Thu, 19 Apr 2007 00:31:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 51EE413C46E for ; Thu, 19 Apr 2007 00:31:36 +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; Wed, 18 Apr 2007 16:59:46 -0700 Received: from [10.251.22.38] (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 39139125ADB; Wed, 18 Apr 2007 17:29:13 -0700 (PDT) Message-ID: <4626B7D7.3060207@elischer.org> Date: Wed, 18 Apr 2007 17:29:11 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <46268689.1080301@elischer.org> <4626932B.20505@elischer.org> <20070418161036.A21780@xorpc.icir.org> In-Reply-To: <20070418161036.A21780@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. 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: Thu, 19 Apr 2007 00:31:36 -0000 Luigi Rizzo wrote: > On Wed, Apr 18, 2007 at 02:52:43PM -0700, Julian Elischer wrote: >> Chuck Swiger wrote: >>> On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote: >>>> I'm contemplating the following changes to functionality: >>>> I'd like suggestions and comments... >>>> >>>> 1/ Commit capability >>>> In this change you declare a new firewall, >>>> and modify/build it, and then you 'commit' it so that >>>> the whole change is atomic. >>> [ ... ] > ... >> I'll try express it better again in a second... >> >> ipfw sets are curently impemented by adding a set number to each rule. >> By enabling and disabling the sets one controls which rules are skipped over, >> however they are still all in the same linked list of rules. >> If you have a set of 1000 rules and disable 999 of them, the packet still >> has to follow 1000 links. > > if what you want is just optimising the walk through rules, > you could do just that, i.e. add a 'the_real_next_rule' field which > gets reset when a significant change occurs (e.g. enable/disable a > set, or add/delete a rule) and initialized lazily the first time > it needs to be dereferenced. > This is the same thing that ipfw does for skipto targets, > so the mechanism is already in place somehow. it is but it doesn't really give me what I want with "efficient computed skipto" I think I'll firm up my proposal a bit before trying to explain too much more, but if I have tow versions of the ruleset.. one a linked list that I can edit easily, and one "compiled" version that is run, then I can put the compiled version int an array and do binary searching to get quickly to a random rule number instead of traversing a possibly long linked list. I can also do some interesting tricks with reference counts on the array, to ensure that I don't hold any lock when traversing the firewall, which allows me to bypass all the problems I am currently seeing with Lock-order-reversals. Iplan on still having the cached hints but that won't work for "skipto tablearg ip from me to any" as 'tablearg' could be anything. > > cheers > luigi