2011/2/27 Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx>: > On Sun, 27 Feb 2011, Anatoly Muliarski wrote: > >> I did oprofile test on our router and I found strange things with >> ipset performance. >> Using a single check of a nethash set with 3 nets in it consumes 1.88% >> of CPU, using a single check of an ipportiphash with zero items >> consumes 3.39% and ip_set module itself consumes 4.9%. >> Currently I am using 2.6.25.17 kernel with ipset v2.4.9. > > That is a really-really old version of ipset. > >> Is it worth to upgrade to ipset v4.5 to resolve this issue? > > I believe so. But please note, I stopped the development of the 4.x branch > and the currently maintained release is 6.x. I upgraded to ipset v4.5 and got no difference :( BTW I had to upgrade iptables too as my old v1.4.1 did not work with set rules. Unfortunately, this fact is not reflected in the manual. Finally I optimized my iptables rules to exclude unncessary checks and remove unused sets, BUT the question is open - what is the cause of losing performance on a simple set check? Why a lot of other iptables rules do not consume so much CPU time? Nevertheless I would like to say personally much thanks for your great tool. It makes a lot of traffic control tasks easier and ever possible. A one small thing that I was missed( exclude /16 limitation for most of the set types and a semantic difference between masks 1-31 and mask 32 ) is a possibility of using ipset facilities with not in the context of a current packet. In other words I was need to store and use later something like a state. But it is only a little strange wish that may not be in line of general development :) > > Best regards, > Jozsef > - > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt > Address : KFKI Research Institute for Particle and Nuclear Physics > H-1525 Budapest 114, POB. 49, Hungary > -- Best regards Anatoly Muliarski -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html