Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+option\s+for\s+large\s+routing\s+hash\s*$/: 14 ]

Total 14 documents matching your query.

1. [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 9 Dec 2003 16:09:07 +0100
I think patch should be useful as it helps performance a lot during high flow load. I have some numbers if you are interested. Cheers. --ro -- net/ipv4/Kconfig.orig 2003-12-09 14:00:14.000000000 +01
/archives/netdev/2003-12/msg00159.html (8,946 bytes)

2. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 9 Dec 2003 12:20:31 -0800
I'm very hesitant about this, and it is not because I don't believe that it brings better performance in your tests on your machines :) Recently there was a thread on linux-kernel by the folks, such
/archives/netdev/2003-12/msg00163.html (9,374 bytes)

3. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 9 Dec 2003 23:28:31 +0100
Yes. I do. Lets look at experiment to start with also we seen people trying to use in real hi-flow environments. pktgen is sending 32 kflows with flowlen 10 packets (64 byte) at 2 * 300 kpps on into
/archives/netdev/2003-12/msg00165.html (10,899 bytes)

4. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 00:15:56 -0800
... ... ... Thanks for the data. I would eventually like an algorithm that uses a min/max range. Perhaps something like: const unsigned long rthash_min = PAGE_SIZE: const unsigned long rthash_max = P
/archives/netdev/2003-12/msg00173.html (9,359 bytes)

5. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 10 Dec 2003 15:47:44 +0100
More thoughts and observations before doing anything else maybe we can wake up Alexey... ... ... ... Some more experiment details. First full Internet routing table was used. Processor UP XEON 2.6 G
/archives/netdev/2003-12/msg00177.html (9,727 bytes)

6. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 15:05:37 -0800
I wish we had resolved that in the long thread we had about it a few months ago. We should really reestablish the point we had reached, and try to make some more forward progress. This problem is not
/archives/netdev/2003-12/msg00199.html (9,828 bytes)

7. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 13 Dec 2003 00:10:16 +0100
No I will not. I revisited the patches and they seems to some help but here must be some other problem too. Seems we have to start over. Well let me add the patch with the debugging from Sarma to sta
/archives/netdev/2003-12/msg00223.html (10,706 bytes)

8. [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 9 Dec 2003 16:09:07 +0100
Hello! I think patch should be useful as it helps performance a lot during high flow load. I have some numbers if you are interested. Cheers. --ro -- net/ipv4/Kconfig.orig 2003-12-09 14:00:14.0000000
/archives/netdev/2003-12/msg00558.html (8,946 bytes)

9. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 9 Dec 2003 12:20:31 -0800
I'm very hesitant about this, and it is not because I don't believe that it brings better performance in your tests on your machines :) Recently there was a thread on linux-kernel by the folks, such
/archives/netdev/2003-12/msg00562.html (9,440 bytes)

10. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 9 Dec 2003 23:28:31 +0100
Yes. I do. Lets look at experiment to start with also we seen people trying to use in real hi-flow environments. pktgen is sending 32 kflows with flowlen 10 packets (64 byte) at 2 * 300 kpps on into
/archives/netdev/2003-12/msg00564.html (11,006 bytes)

11. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 00:15:56 -0800
... ... ... Thanks for the data. I would eventually like an algorithm that uses a min/max range. Perhaps something like: const unsigned long rthash_min = PAGE_SIZE: const unsigned long rthash_max = P
/archives/netdev/2003-12/msg00572.html (9,495 bytes)

12. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Wed, 10 Dec 2003 15:47:44 +0100
Hello! More thoughts and observations before doing anything else maybe we can wake up Alexey... ... ... ... Some more experiment details. First full Internet routing table was used. Processor UP XEON
/archives/netdev/2003-12/msg00576.html (9,727 bytes)

13. Re: [PATCH] option for large routing hash (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 15:05:37 -0800
I wish we had resolved that in the long thread we had about it a few months ago. We should really reestablish the point we had reached, and try to make some more forward progress. This problem is not
/archives/netdev/2003-12/msg00598.html (9,894 bytes)

14. Re: [PATCH] option for large routing hash (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Sat, 13 Dec 2003 00:10:16 +0100
No I will not. I revisited the patches and they seems to some help but here must be some other problem too. Seems we have to start over. Well let me add the patch with the debugging from Sarma to sta
/archives/netdev/2003-12/msg00622.html (10,813 bytes)


This search system is powered by Namazu