On Sat, Oct 01, 2005 at 08:50:13AM -0500, Travis H. wrote: > > Yeah, I neglected stateful matching. I should have said that every > packet that has to run the gauntlet of rules, has to run all of them. > Subsequent reading of the PF FAQ confirms that there's no deep > evaluation-reordering magic going on, that quick rules really are > faster.
i'd VERY much like to see someone put up a short little www-type ( or whatever ) illustration of how they were really experiencing a service-affecting performance degredation which was solved by the use of 'quick' in their ruleset. mathematically, yeah, less rules to evaluate = faster, but without someone bucking up and making a nice demonstration of why they needed to do 'quick' a lot, the ~tri-monthly discussion of someone being upset about the last-match thing (on misc@ or pf@) is kind of a bit worn out... :/ most times people say that they have some $BIGNUM line ruleset and so they think they need to use quick even if they're keeping state, but outside of the human shock value of $BIGNUM, there's not much in the way of proof that people show (unless i'm being an archive amnesiac) for needing to go 'quick'ing everything, or otherwise making a case that 'quick' should be the implicit default and 'slow' be added to take its place after the pf-first-match conversion, or people wanting a 'set evaluation [first|last]' knob. even little soekrises are really hurting for speed some times, but from my small experience with them one would probably end up gagging on interrupts before one would run into a brick wall due to not using 'quick' a lot. jared -- [ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
