Jan Engelhardt wrote:
On Dec 29 2007 19:54, Krzysztof Oledzki wrote:
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.
As a short-term workaround one can use taskset to force running iptables on
CPU#0.
Actually, on one (but fixed) arbitrary core.
Indeed, what a mess. I was just about to commit a patch to
always use first_cpu(cpu_possible_map) for copy_entries_to_user,
but thats no enough, we also need to force ruleset replacement
to choose the same CPU. This effectively eliminates all performance
improvements of the NUMA optimizations during ruleset updates.
Its ugly (not much more than other parts of iptables though),
but we should be able to keep half the improvement by using
raw_smp_processor_id() for ruleset replacements and storing
that number for the next copy_entries_to_user operations.
Alternatively we could flag the matches and targets requiring
this and fix them up during the second pass (counter fixup).
Most of them are rather rarely used I guess (limit, hashlimit,
quota and statistic).
Eric, do you have any better suggestions how to fix this?
-
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
