Luigi Rizzo wrote:
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.
you can't do it at insertion time if it's a tablearg style skipto..
but such a rule will simply continue at the next rule as if it
did not match.
cheers
luigi
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"