At 10:08 AM 9/19/2005, Jeremie Le Hen wrote: >OTOH, I agree with Luigi about the "resume" keyword. This introduces >a kind of linked-lists, but this is just syntactic sugar and I can't >see any performance improvement with this.
I think that a few examples might show why it'd be more than syntactic sugar. Let's take the one I just sent to Luigi: pipe 17 tcp from 0.0.0.1 to any 80 in via tun* established resume 5000 Let's look at how would you render this without the "resume 5000" at the end. There are really three ways: 1) You could duplicate all of the conditions in a "skipto" rule, which would be inefficient because all the matching would be done twice. 2) You could do a "skipto around a skipto", but this would require at least four rules (including a final jump target) if you generated it automatically in one pass or wanted it to be maintainable by hand without tedious manual renumbering. 3) You could DeMorganize, which is very inefficient on matching packets and generates extremely complex rulesets. >This might be worth to have >but I'm a little but scared about adding such options because there >would be no reason then to not add other syntactic facilities, which >would end up messing the whole syntax. I am concerned about this too, and that's why I suggested "resume" as a trailing option. IPFW rules currently have all kinds of trailing options, involving everything from test for arcane TCP flags to "verrevpath" (a firewall function which incurs a lot of overhead but is quite powerful). A "resume" option wouldn't introduce any backward incompatibilities, and if the user didn't know about it, it would not get in the way. I agree with you that the ability to negate the "AND" of all conditions in the rule would greatly clarify some rulesets. I know it would help with many of mine! --Brett Glass _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
