Re: Migration to PF - some questions

[jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>]

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 ]