Le 2012-09-04 13:52, Claudio Jeker a écrit :
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 know this but the problem is that it always come in batch like 10
dropped paquets every 40 minutes so this is affecting voip and some
player lost their game connectivity, etc.
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)?
Some answer mention it so I thinked it was a diagnostic tool that could
be helpfull but maybe the wanted to make sure that I was disabled and
that I didn't understand first.
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.
Perfect, that what I needed to know. That meen that I don't need this
optimizer since I already do my own optimisation with anchor.
Thanks
--
Michel Blais
Administrateur réseau / Network administrator
Targo Communications
www.targo.ca
514-448-0773
