[Bug 773] iptables performance limits on # of rules using ipset

[bugzilla-daemon at bugzilla.netfilter.org]

http://bugzilla.netfilter.org/show_bug.cgi?id=773

--- Comment #4 from Jozsef Kadlecsik <kadlec at netfilter.org> 2012-03-01 15:25:48 CET ---
> > To give you a bit more details, if I create just one empty 1 ipset and then
> > build 29 identical dummy iptables rules (dummy in the sense that the rules will
> > never match any of the test packets) that use this single empty ipset , I still
> > can reproduce the problem. Just wanted to let you know this is not tied to the
> > number of ipsets but just the number of iptables rules that refer to ipset. 
> > 
> > I have not checked if the behavior applies to other types of ipsets than the
> > ipportiphash. This would be something fast for me to check if it helps knowing
> > / confirming what you suspect.  

You can easily check with any other set type. I'd guess the result would be the
same.

> > While I will not be able to use 2.6.34, I'll try to take a different Linux
> > distribution just to confirm whether this performs better on newer releases. 
> > 
> > Is this spin lock acquired every time a packet is processed? 

Yes, it's acquired at processing every packet and every rule. But it's still a
guessing why the performance drops.

In 6.x the lock was removed.

> > It's not easy to imagine how a lock related bottleneck would not seem to have
> > almost any impact for up to 24 rules and then cause a very significant
> > performance impact lightly above that # of rules threshold.
> 
> One more related question if you can advise. Since I don't have the option to
> upgrade the OS, I may be able to limit my rules to not exceed the threshold
> that causes performance issues. 
> To do so, I think I need to have an ipsets with more than 64k entries (the
> current max). Is changing this max as simple as doubling MAX_RANGE in ip_set.h
> and recompiling ipset? or are there other dependency? Not I only use
> ipportiphash in case this makes the workaround any simpler.  
> 
> /* General limit for the elements in a set */
> #define MAX_RANGE 0x0000FFFF

You can hack ipset 4.x that way, the MAX_RANGE value was just a safety belt in
order to prevent exhausting the memory accidentally. But if you know what you
are doing, then you can remove that limit.

Best regards,
Jozsef

-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.