Re: ipfw add skipto tablearg....
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. one COULD, but I know I use this feature only with a number (20 or less) following rules, each of which is a skipto itself to some further awat location...or a simple drop.. Shall we say we leave it as an exercise for the reader ? 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 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw add skipto tablearg....
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]
Re: ipfw add skipto tablearg....
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 ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
