[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1572280.6B6hWj6GJJ@h2o.as.studentenwerk.mhn.de>
Date: Wed, 23 Oct 2013 19:01:57 +0200
From: Wolfgang Walter <linux@...m.de>
To: netdev@...r.kernel.org
Cc: David Miller <davem@...emloft.net>, hannes@...essinduktion.org,
klassert@...hematik.tu-chemnitz.de
Subject: 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:
> > Am Mittwoch, 23. Oktober 2013, 05:00:01 schrieb Eric Dumazet:
> > > On Wed, 2013-10-23 at 13:33 +0200, Wolfgang Walter wrote:
> > > > 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists