From owner-freebsd-net@FreeBSD.ORG Tue Aug 19 18:06:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F342106566B for ; Tue, 19 Aug 2008 18:06:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id EFEC28FC12 for ; Tue, 19 Aug 2008 18:06:20 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id m7JI65q3042351; Wed, 20 Aug 2008 04:06:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 20 Aug 2008 04:06:05 +1000 (EST) From: Ian Smith To: Luigi Rizzo In-Reply-To: <20080819133101.GA23276@onelab2.iet.unipi.it> Message-ID: <20080820031409.V41971@sola.nimnet.asn.au> References: <48926C02.6030308@elischer.org> <20080819133101.GA23276@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org, Julian Elischer Subject: Re: ipfw add skipto tablearg.... 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, 19 Aug 2008 18:06:21 -0000 On Tue, 19 Aug 2008, Luigi Rizzo wrote: > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote: > > On Thu, 31 Jul 2008, Julian Elischer wrote: > ... > > > ipfw add 1000 skipto tablearg ip from any to table(31) > ... > > > see attached patch... (hopefully not stripped) > > > > > > Of course it is hoped that the rules you are skipping to are nearby > > > as it iterates through the rules following the skipto to find the > > > target, > > > > 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? > > 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 spam syslogd in the general case, but maybe reporting target < current rule for such dynamic forms of skipto might highlight config errors? I should STFU and resume lurking unless I can contribute code, I know. cheers, Ian