Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*2\.6\.7\s+tulip\s+performance\s+$with\s+NAPI$\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*2\.6\.7\s+tulip\s+performance\s+$with\s+NAPI$\s*$/: 26 ]

Total 26 documents matching your query.

1. 2.6.7 tulip performance (with NAPI) (score: 1): Author: xpob@xxxxxxxxx>; Date: Tue, 05 Oct 2004 16:42:44 -0700; NOTE: This test machine is running a P-IV 2.8Ghz processor, 32/33 PCI bus, 512MB RAM, and kernels compiled for the P-IV processor. I am using a modified pktgen that can receive as well as transmit p; /archives/netdev/2004-10/msg00191.html (10,145 bytes)
2. 2.6.7 tulip performance (with NAPI) (score: 1): Author: . Miller" <davem@xxxxxxxxxxxxx>; Date: Wed, 6 Oct 2004 21:21:55 +0200; If you have "max_before_softirq" in your version pktgen you can try it to balance your load. HZ=1000 in 2.6 can make scheduling different. --ro; /archives/netdev/2004-10/msg00220.html (8,718 bytes)
3. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: s Romieu <romieu@xxxxxxxxxxxxx>; Date: Wed, 06 Oct 2004 14:37:11 -0700; If you have "max_before_softirq" in your version pktgen you can try it to balance your load. HZ=1000 in 2.6 can make scheduling different. Yes, I was able to get it to smooth out by doing something l; /archives/netdev/2004-10/msg00224.html (10,289 bytes)
4. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Wed, 06 Oct 2004 17:56:05 -0700; Ben Greear wrote: On a related note, I am now working on a way to use a hook in the netif_wake_queue callback to wake up pktgen. This should allow me to have a pktgen that does not need to spin in a; /archives/netdev/2004-10/msg00230.html (153,493 bytes)
5. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: xx>; Date: Wed, 6 Oct 2004 18:08:26 -0700; This sort of suggests that pktgen may be better implemented via a kind of special queueing discipline. Just an idea.; /archives/netdev/2004-10/msg00238.html (9,338 bytes)
6. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: xx>; Date: Thu, 07 Oct 2004 11:09:14 -0700; David S. Miller wrote: On Wed, 06 Oct 2004 17:56:05 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: It may be that other programs would like to use the notify_queue_woken hook, so if this were ever; /archives/netdev/2004-10/msg00257.html (11,151 bytes)
7. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author:; Date: Thu, 7 Oct 2004 23:11:47 +0200; Interesting... I got requests for higher performance in flow/DoS testing to be really useful. Probably only preallocation will help here. To be really aggressive we could hack the driver TX handling; /archives/netdev/2004-10/msg00265.html (10,455 bytes)
8. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: xxxxxx>; Date: Thu, 07 Oct 2004 14:47:45 -0700; Interesting... I got requests for higher performance in flow/DoS testing to be really useful. Probably only preallocation will help here. To be really aggressive we could hack the driver TX handling; /archives/netdev/2004-10/msg00268.html (11,791 bytes)
9. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: . Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 8 Oct 2004 00:13:44 +0200; Yes the board has 4 different PCI-bus from what I remember it's was a Supermicro X5DL8-GG. Yes you need bus bandwith from what I've seen even 133 MHz PCI-X is limiting the small packet performance at; /archives/netdev/2004-10/msg00272.html (10,400 bytes)
10. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author:; Date: Fri, 8 Oct 2004 01:44:13 +0200; If you're interested in raw pps numbers and willing to use something other than pktgen to attain them, you might want to look into the intel IXP-based boards. You actually have to write some microcod; /archives/netdev/2004-10/msg00274.html (9,856 bytes)
11. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Casson Leighton <lkcl@xxxxxxxx>; Date: Fri, 08 Oct 2004 10:25:13 +0100; Lennert Buytenhek wrote: On Thu, Oct 07, 2004 at 11:11:47PM +0200, Robert Olsson wrote: I'm interested if anyone has done any pktgen performance tests with w. S2IO or other 10G card we need to upgrad; /archives/netdev/2004-10/msg00282.html (10,613 bytes)
12. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: lkcl@xxxxxxxx>; Date: Fri, 8 Oct 2004 11:28:27 +0200; I'm on the Radisys ENP-2611 too. Now that 2.6.9-rc3 runs on the ENP-2611 out-of-the-box, and the Fedora Core 2 port mostly works, I should have a fairly complete set of Free microcode plus supporting; /archives/netdev/2004-10/msg00283.html (10,611 bytes)
13. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: . Miller" <davem@xxxxxxxxxxxxx>; Date: Sun, 10 Oct 2004 21:07:46 -0700; VLAN devices are simply virtual devices. There is a real netdev structure backing them, and thus you can point queueing disciplines et al. to them just like any other device. So that's the idea, some; /archives/netdev/2004-10/msg00344.html (9,732 bytes)
14. 2.6.7 tulip performance (with NAPI) (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Tue, 05 Oct 2004 16:42:44 -0700; Hello! NOTE: This test machine is running a P-IV 2.8Ghz processor, 32/33 PCI bus, 512MB RAM, and kernels compiled for the P-IV processor. I am using a modified pktgen that can receive as well as tran; /archives/netdev/2004-10/msg01689.html (9,801 bytes)
15. 2.6.7 tulip performance (with NAPI) (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Wed, 6 Oct 2004 21:21:55 +0200; If you have "max_before_softirq" in your version pktgen you can try it to balance your load. HZ=1000 in 2.6 can make scheduling different. --ro; /archives/netdev/2004-10/msg01718.html (8,766 bytes)
16. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Wed, 06 Oct 2004 14:37:11 -0700; If you have "max_before_softirq" in your version pktgen you can try it to balance your load. HZ=1000 in 2.6 can make scheduling different. Yes, I was able to get it to smooth out by doing something l; /archives/netdev/2004-10/msg01722.html (10,233 bytes)
17. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Wed, 06 Oct 2004 17:56:05 -0700; On a related note, I am now working on a way to use a hook in the netif_wake_queue callback to wake up pktgen. This should allow me to have a pktgen that does not need to spin in a tight loop like i; /archives/netdev/2004-10/msg01728.html (153,318 bytes)
18. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Wed, 6 Oct 2004 18:08:26 -0700; This sort of suggests that pktgen may be better implemented via a kind of special queueing discipline. Just an idea.; /archives/netdev/2004-10/msg01736.html (9,466 bytes)
19. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Thu, 07 Oct 2004 11:09:14 -0700; It may be that other programs would like to use the notify_queue_woken hook, so if this were ever to hit the kernel proper, might want to make this a linked list of callbacks instead of a simple poi; /archives/netdev/2004-10/msg01755.html (11,211 bytes)
20. Re: 2.6.7 tulip performance (with NAPI) (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Thu, 7 Oct 2004 23:11:47 +0200; Interesting... I got requests for higher performance in flow/DoS testing to be really useful. Probably only preallocation will help here. To be really aggressive we could hack the driver TX handling; /archives/netdev/2004-10/msg01763.html (10,583 bytes)

Current List: 1 - 20
Page: [1] [2]