Re: debugging kernel during packet drops

[Jorrit Kronjee <j.kronjee@infopact.nl>]

Eric,

Changing the "expire"-value doesn't seem to have much effect, since the
traffic I'm sending updates the expiration value too regularly anyway.
However, changing the garbage collector interval made the amount of
interrupts drop from ~1900 irqs/s to ~50 irqs/s according to perf top.

I tried cranking up the traffic to see how far I can push it, but I'm
starting to reach the limitations of my DoS machine. I can now bridge
about 390 kpps without any packet drops.

Regards,

Jorrit Kronjee

On 3/26/2010 3:17 PM, Eric Dumazet wrote:
> Le vendredi 26 mars 2010 à 11:41 +0100, Jorrit Kronjee a écrit :
>
>   
>> And iptables-save -c produced this:
>> # Generated by iptables-save v1.4.4 on Fri Mar 26 11:24:59 2010
>> *filter
>> :INPUT ACCEPT [1043:60514]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [942:282723]
>> [99563191:3783420610] -A FORWARD -m hashlimit --hashlimit-upto 10000/sec
>> --hashlimit-burst 100 --hashlimit-mode dstip --hashlimit-name hashtable
>> --hashlimit-htable-max 131072 --hashlimit-htable-expire 1000 -j ACCEPT
>> [0:0] -A FORWARD -m limit --limit 5/sec -j LOG --log-prefix "HASHLIMITED
>> -- "
>>     
> Hmm, --hashlimit-htable-expire 1000 & gcinterval 1000 (default) are very
> aggressive.
>
> That might explain high number of spinlocks/unlocks (many entries are
> inserted/deleted per second)
>
> I would let entries forever in table (no more expensive locks/unlocks)
>
> --hashlimit-htable-expire 100000
> --hashlimit-htable-gcinterval 3600000   (garbage collect every hour)
> --hashlimit-htable-size 65536
>
>
>   

-- 
Manager ICT

Infopact Network Solutions
Hoogvlietsekerkweg 170
3194 AM  Rotterdam Hoogvliet
tel. +31 (0)88 - 4636700
fax. +31 (0)88 - 4636799
j.kronjee@infopact.nl
http://www.infopact.nl/ 


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html