[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 #2 from Al <aas029 at yahoo.com> 2012-02-29 18:43:30 CET ---
(In reply to comment #1)
> This is the old ipset branch, which protects the sets with a single spinlock. I
> suspect that is the reason for the performance degradation.
> 
> The development of ipset is focused on the ipset 6.x branch. I don't have free
> resource to work on the old branch, so please try to upgrade (but it needs at
> least kernel 2.6.34).

Hi Jozsef,
Thanks for the very quick response. 

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.  

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? 

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.

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