Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Route\s+cache\s+performance\s*$/: 72 ]

Total 72 documents matching your query.

1. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Tue, 6 Sep 2005 16:57:00 -0700
Woot! Yes, this is the difference. With the patch applied (ajust directly freeing the dst_entry), everything balances easily, there are no overflows, and the result of rt_may_expire() looks very reas
/archives/netdev/2005-09/msg00004.html (10,309 bytes)

2. Re: Route cache performance (score: 1)
Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 05:19:59 +0400
... .. It is supposed to work. :-) The problem is like an unkillable zombie. Robert, have you seen this pehonomenon already? Did you mean that SMP works or that it never works (but this patch is val
/archives/netdev/2005-09/msg00005.html (10,630 bytes)

3. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 7 Sep 2005 16:45:03 +0200
Packet processing happens in RX_SOFIRQ. NAPI or non-NAPI is no difference with RCU deferred delete this should happen by the RCU-tasklet when tasklets are run after the real SOFTIRQ's. There is a lim
/archives/netdev/2005-09/msg00006.html (10,893 bytes)

4. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 7 Sep 2005 17:03:17 +0200
It was quite some time since I saw dst cache overflow and we use 2.6 in infrastructure. Anyway I was able to "tune" route cache so I see in our lab system on a SMP box. I think UP and SMP behaves the
/archives/netdev/2005-09/msg00007.html (10,245 bytes)

5. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 09:28:54 -0700
Yes, setting maxbatch to 10000 also results in working gc, though routing throughput is about 5.7% higher when just calling dst_free directly. There was discussion about this before (recycling of exi
/archives/netdev/2005-09/msg00008.html (10,922 bytes)

6. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 7 Sep 2005 18:49:03 +0200
Oh that's good news... You loose 5.7% for rDoS but should benefit in normal conditions. It's called trade-off's :) rDoS is hardly nomal case? But maybe it's time to compare routing via route hash vs
/archives/netdev/2005-09/msg00009.html (10,892 bytes)

7. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 09:55:28 -0700
I believe what I've been seeing is a _reduction_ in performance in both the e1000 driver and other parts of the kernel that result in it handling these packets much more slowly than in 2.4. The dst c
/archives/netdev/2005-09/msg00010.html (10,934 bytes)

8. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 09:57:58 -0700
I haven't even filled the route tables yet. I've just been testing with a bog standard table (three /24s and one /0). Simon
/archives/netdev/2005-09/msg00011.html (10,485 bytes)

9. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 7 Sep 2005 19:21:14 +0200
If route hash setup is identical, buckets etc and HZ is same etc. I have no idea about the performance difference. Somebody else? In other case you need to compare (o)profiles and see if this can giv
/archives/netdev/2005-09/msg00012.html (10,444 bytes)

10. Re: Route cache performance (score: 1)
Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Wed, 7 Sep 2005 23:59:11 +0400
Could you try lower values? F.e. I guess 300 or a little more (it is netdev_max_backlog) should be enough. 5.7% is not "really hurts" yet. :-) Alexey
/archives/netdev/2005-09/msg00013.html (11,004 bytes)

11. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Tue, 13 Sep 2005 15:14:48 -0700
300 seems to be sufficient, but I'm not sure what this depends on (load, HZ, timing of some sort?). See below for full tests. I decided to try out FreeBSD in comparison as I've heard people saying th
/archives/netdev/2005-09/msg00026.html (15,312 bytes)

12. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 14 Sep 2005 10:04:21 +0200
Yes. This is single flow? Strange. Run a fixed size shot 10Mpkts pkts or so for both 2.4 and 2.6 and save /proc/interrupts, proc/net/softnetstat, netstat -i, tc -s qdisc to start with. A profile on 2
/archives/netdev/2005-09/msg00033.html (11,356 bytes)

13. Re: Route cache performance (score: 1)
Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 01:04:32 +0400
It should be enough not depending on anything but sysctl net/core/netdev_max_backlog. It could, but it does not. Still. Unfortunately. It caches lots of information depeding on incoming interface an
/archives/netdev/2005-09/msg00034.html (13,445 bytes)

14. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Thu, 15 Sep 2005 23:30:54 +0200
No. There must be an explanation... I've seen around 1 Mpps in the best single flow tests w. 2.6 kernels of course decent HW. Simon can you report in pps as you use 64 byte pkts. Yes. I'll guess the
/archives/netdev/2005-09/msg00035.html (10,991 bytes)

15. Re: Route cache performance (score: 1)
Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 02:21:02 +0400
Sender: 367 Mbps, 717883 pps valid src/dst, 64 byte (Ethernet) packets 2.4.27-rc1: 297 Mbps forwarded (w/idle time?!) So, his best number is (717883/367)*297 ~= 580kpps RCU should not add essential
/archives/netdev/2005-09/msg00036.html (11,135 bytes)

16. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 16 Sep 2005 14:18:01 +0200
Yes sounds famliar XEON with e1000... So why not for 2.6? Below a very quick test from our 1.6 GHz Opteron. Latest GIT tree w. UP. e1000 at PCI-X 133/100 MHz. 82546 GB dual NIC's Input 881 kpps.into
/archives/netdev/2005-09/msg00038.html (11,913 bytes)

17. Re: Route cache performance (score: 1)
Author: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 23:04:04 +0400
Most likely, something is broken in the e1000 driver. Otherwise, no ideas. I do not see _why_. Apparently some overhead is present but I do not understand why it is so large. Is it just because 300
/archives/netdev/2005-09/msg00039.html (10,803 bytes)

18. Re: Route cache performance (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 12:22:27 -0700
Yes sounds famliar XEON with e1000... So why not for 2.6? Most likely, something is broken in the e1000 driver. Otherwise, no ideas. Has anyone tried using bridging to compare numbers? I would assum
/archives/netdev/2005-09/msg00040.html (11,423 bytes)

19. Re: Route cache performance (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 16 Sep 2005 21:57:31 +0200
No it's hard to guess. Simon will hopefully bring some more data. Yes when RX softirq is done. RCU tasklet has to take over and probably reload cache with some the entries to complete the deletion. I
/archives/netdev/2005-09/msg00041.html (10,727 bytes)

20. Re: Route cache performance (score: 1)
Author: Simon Kirby <sim@xxxxxxxxxxxxx>
Date: Fri, 16 Sep 2005 17:28:23 -0700
I got stuck in some mud again, but I was able to run a small oprofile. nf_iterate was near the top even though the firewall was empty, so I changed CONFIG_IP_NF_IPTABLES=y to CONFIG_IP_NF_IPTABLES=m
/archives/netdev/2005-09/msg00042.html (11,631 bytes)


This search system is powered by Namazu