ipfw add skipto tablearg....

Luigi Rizzo rizzo at iet.unipi.it
Tue Aug 19 18:21:07 UTC 2008

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.


More information about the freebsd-ipfw mailing list