Fwd: Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4

Am Mittwoch, 23. Oktober 2013, 09:17:30 schrieben Sie:

On Wed, 2013-10-23 at 17:57 +0200, Wolfgang Walter wrote:

quoted

Am Mittwoch, 23. Oktober 2013, 05:00:01 schrieb Eric Dumazet:

quoted

On Wed, 2013-10-23 at 13:33 +0200, Wolfgang Walter wrote:

quoted

I don't know what this value actually means. But on 3.4.x it is much
higher. On a machine with 512MB ram it is 32768, on a machine with 1GB
ram it is 262144 and with 16GB ram it is 4194304.

Such huge values should not be needed. We should have at most one dst
per packet in flight.

On a loaded router, a NIC not using BQL could queue around 16,000
packets.

Of course, Qdisc layers could also store a lot of packets, but using the
default pfifo_fast is only adding 1000 packets per interface.

I guess using 65536 as the default value should be safe and reasonable

Have you tried using 32768 or 65536 ?

I use 32768 on routers with 512MB. They usually have around 50
ipsec-tunnels and only about 10 interfaces including vlan-interfaces.

On larger ones I set the bigger values from 3.4.x. That one with 16GB has
about 2000 ipsec-tunnels. It has about 80 interfaces (inlcuding vlan-
interfaces). Physically it has 8 interfaces with together about 30
hardware- queues.

offlist

OK, but you do not have the idea of actual number of entries ?

If you use SLAB, you probably can try "grep dst /proc/slabinfo"

Ah, ok. I use SLUB, but SLABINFO=y.

Without much traffic it is:

# grep dst /proc/slabinfo
xfrm_dst_cache      4435   4608    448   36    4 : tunables    0    0    0 : 
slabdata    128    128      0

on the big one. 

I can recompile the kernels with SLAB instead of SLUB if SLAB gives more 
usefull infos.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts