On Tue, Sep 04, 2012 at 10:16:41AM -0400, Michel Blais wrote: > I've build a Xeon E3 with Intel i340 ethernet with 82580 chip. > > CPU is use up to 24% on the first core, congestion is now at 0.3/s. > > I still see drops in net.inet.ip.ifq.drops. 1131 drops in 81 hours.
1131 pkts dropped in 81hours or 291600 seconds. That is one packet every 4 minutes. That should not cause any trouble at all. Such drops can happen because the softnet interupt is unable to run for a long time. E.g. because of some magic SMM/NMI taking you CPU out for lunch. In which case you will get a massive burst once the CPU is back at work. > I'm now trying kern.pool_debug=1 but don't know where the > output will go and can't find anything about the output. Will it > be in dmesg or in a log ? What do you hope the get with enabling the pool corruption checker (apart from a slower machine)? > Also I would like to write again my rule but you like to know more > about PF's ruleset optimization mechanisms. I see in pf.conf man > page the following : > > Basic ruleset optimization does four things to improve the > performance of ruleset evaluations: > 1. remove duplicate rules > 2. remove rules that are a subset of another rule > 3. combine multiple rules into a table when advantageous > 4. re-order the rules to improve evaluation performance > > I can handle 1, 2 and 3 fine without the optimisation but for the > order of the rule, is there any doc on how to optimise the order > of the rule order for best performance ? I was also not able to > find anything about this. Rule evaluation happens in a certain order. The optimizer reorders the rules so that skip steps can do a better job (e.g. moving rules with the same source IP together). In general rules are evaluated in an order that is roughly interface, direction, rdomain, AF, proto, source IP and dst IP. If there is no match pf calculates something called skip steps which is a hint where to jump to in case of a failed match. In other words if all rules for em0 come first and the packet enters em1 we can skip all those rules after the first test. After the basic tests the proto is checked and additional per protocol evaluation happen (like TCP flags, ports, uid/gid checks...). These checks are not part of skip steps and are not influenced by the optimizer. Only the first 7 matter and are optimized. -- :wq Claudio
