Jan Engelhardt wrote:
On Dec 28 2007 17:50, Patrick McHardy wrote:
And my bigtime question would be: where is the other counter
actually? struct xt_quota_info only has one counter! Does
netfilter secretly allocate matchinfos per-cpu?
Not secretly, but yes, the entire ruleset exists once per CPU. That
also seems to be the problem, at the time the master idea was thought
of we always dumped entries from CPU 0, today its from the current
CPU, but the only one that actually has correct counters is CPU 0.
The easy fix would be to revert to that behaviour, but maybe someone
can come up with a better idea that doesn't involve walking over the
entire ruleset and resycing things or adding dump callbacks to
matches.
Well, the short term fix would be to turn
q->master = q
into
q->master = percpu_get(0, q)
or whatever is appropriate.
That doesn't help, the problem is that we keep only the counters on
CPU0 up to date, but the data copied to userspace during iptables -L
is chosen by the CPU the iptables command is running on.
In the long run, separating the rule from the matchinfo data would be
beneficial. Or actually - why cannot the ruleset exists once for all
CPUs? The write path is a slow path anyway / it is read-mostly anyway.
Mainly because of the counters, we don't want to have all CPUs fighting
for the cachelines.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
