Date: Tue, 19 Aug 2008 15:31:01 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Ian Smith <smithi@nimnet.asn.au> Cc: FreeBSD Net <freebsd-net@freebsd.org>, ipfw@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: ipfw add skipto tablearg.... Message-ID: <20080819133101.GA23276@onelab2.iet.unipi.it> In-Reply-To: <Pine.BSF.3.96.1080819152451.21367A-100000@gaia.nimnet.asn.au> References: <48926C02.6030308@elischer.org> <Pine.BSF.3.96.1080819152451.21367A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080819133101.GA23276>