* Peus, Christoph <christoph.p...@uni-wh.de> [2015-06-15 20:40]: > I'm currently planning for a complete reorganization i.e. rewrite of a > historically grown pf.conf of about 300 rules. Up to now each and every rule > uses the "quick" keyword, which effectively turns the "last match" concept of > pf into a "first match" one. Does that make any sense?
mostly a matter of personal preference. quick performs slightly better obviously; I highly doubt w/ just 300 rules you'll even get a measurable difference tho. > Of course.. as evaluation stops at a matching rule with "quick" one may expect > that the average time it takes to decide whether a packet is passed or blocked > is significantly lower and therefore overall performance of pf will be better > with always using "quick". But is this true? depends on your definition of significant :) > Does this make sense if the CPUs > are idling most of the time? Are there any rules of thumb when to use "quick" > and when to avoid it? in general, don't worry too much about performance impact from the way you write your rules. in 99+% of the cases pf is so efficient that it doesn't matter anyway, and the ruleset optimizer, skip steps et al do their job so that you can concentrate on a ruleset optimized for the human dealing with it, not the machine. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
