From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 19 18:21:07 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1171065672; Tue, 19 Aug 2008 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 634F18FC08; Tue, 19 Aug 2008 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BA5687308B; Tue, 19 Aug 2008 20:23:37 +0200 (CEST) Date: Tue, 19 Aug 2008 20:23:37 +0200 From: Luigi Rizzo To: Ian Smith Message-ID: <20080819182337.GA25703@onelab2.iet.unipi.it> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> <20080820031409.V41971@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080820031409.V41971@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw add skipto tablearg.... 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: Tue, 19 Aug 2008 18:21:07 -0000 On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote: > On Tue, 19 Aug 2008, Luigi Rizzo wrote: > > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: ... > > > Until $someone adds a direct skipto target jump at the virtual machine > > > code level - big recalc hit when adding/deleting rules/sets I suppose - > > > it's still the fastest way to get from a to b, where b > a > > > > you mean with tables-based skipto targets ? Because the regular > > skipto has been a constant-time op forever, even in ipfw1 i believe, > > invalidating the target cache on a change and recomputing it the > > fly at the first request. > > Thanks; I'd completely missed the caching of skipto targets before, and > it's all so well commented too. blushing, but glad for the good news. > > But yes I was pondering Julian's patch, which has to lookup_next_rule > every time, and also Mike's bending of divert reentry rule number in > ipfw-classifyd with similar intent, which also has to hunt forward in > linear time for its target rule - or am I missing something else here? well, you can use a hash table to support that. It shouldn't be so bad to implement, flow tables already use hash tables so one can reuse the same code. > > > Speaking of which, should ipfw whinge when asked to skip backwards, > > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd > > > and a local test months ago. > > > > right... but the error can only be reliably detected in the kernel, > > as the rule number is not always known when the rule is added. > > Yes I meant at run-time. On second thoughts, it'd be too easy a way to actually you can do it at insertion time, it's just that you cannot do it in userland as other checks before inserting the rule. cheers luigi