On Dec 30 2007 18:36, Patrick McHardy wrote:
> 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.
>
> 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).
Hmph, how are matches supposed to work with it at all?
Assume this:
static int ...check...(...)
{
struct my_match_info *info = matchinfo;
info->foobar = kmalloc(...);
}
->checkentry() is only called once for each rule, but if each
rule has its own data space (e.g. info->foobar), then that sucks.
-
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
