Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Tx\s+queueing\s*$/: 54 ]

Total 54 documents matching your query.

1. Tx queueing (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Fri, 19 May 2000 01:10:12 +1000
A number of drivers do this: start_xmit() { netif_stop_queue() ... if (room for another packet) netif_wake_queue() ... } I suspect this is a simple port from the dev->tbusy days. It would seem to be
/archives/netdev/2000-05/msg00062.html (9,885 bytes)

2. Re: Tx queueing (score: 1)
Author: Cacophonix <cacophonix@xxxxxxxxx>
Date: Thu, 18 May 2000 09:20:30 -0700 (PDT)
netperf aggregate outbound tcp thruput (Mb/s) between linux-linux and linux-bsd, using a single GA620 2.2.16-1 => 1cpu = 496, 2cpu = 458 2.3.99-pre6 => 1cpu = 568, 2cpu = 626 freebsd 4.0 => 1cpu = 36
/archives/netdev/2000-05/msg00063.html (8,023 bytes)

3. Re: Tx queueing (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Thu, 18 May 2000 12:37:53 -0400 (EDT)
Yes, it's likely from a blind search-and-substitute. Using stop_queue() and wake_queue() in the transmit path is part of the reason why the 2.3 changes are bogus. It is not possible, with these seman
/archives/netdev/2000-05/msg00064.html (10,526 bytes)

4. Re: Tx queueing (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Fri, 19 May 2000 03:01:37 +1000
Burn them boats :) I've been looking for a compatibility header which maps netif_stop_queue() into dev->tbusy manipulation, but I can't find one. Have I missed something? Does it make that much diffe
/archives/netdev/2000-05/msg00065.html (10,063 bytes)

5. Re: Tx queueing (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Thu, 18 May 2000 14:08:20 -0400 (EDT)
David Hinds has compatibility macros. But he can be more pragmatic about the network drivers than I am. It only has to work well enough for his PC Card system, it doesn't have to be The Right Thing.
/archives/netdev/2000-05/msg00066.html (9,941 bytes)

6. Re: Tx queueing (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Thu, 18 May 2000 20:07:51 +0200
The Intel e100 driver implicitely documents it in C source. They unfortunately use a very ugly method to implement it (own UDP/IP header parsing instead of CHECKSUM_HW). I was even porting it to your
/archives/netdev/2000-05/msg00067.html (9,609 bytes)

7. Re: Tx queueing (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 18 May 2000 22:00:29 -0400 (EDT)
OK, Andrew, i know i am not as entertaining as some people, but i can try ... Damn Aussie! This seems fine to me. In 2.3, the device is already serialized by the txmit lock at this point. So your pro
/archives/netdev/2000-05/msg00069.html (12,588 bytes)

8. Re: Tx queueing (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 18 May 2000 22:02:43 -0400 (EDT)
Amy Fong and I have done some tests with much higher throughputs on 2.3 with the GA-620. What was the h/ware you used? What was the MTU you used? cheers, jamal
/archives/netdev/2000-05/msg00070.html (8,112 bytes)

9. Re: Tx queueing (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 18 May 2000 22:14:00 -0400 (EDT)
Typically, the stop will be done on the tx path and the wakeup on the receive path. Well, i think backward compatibility is a philosphy that Linux gas never conformed to anyways ;-> I would say it is
/archives/netdev/2000-05/msg00071.html (9,134 bytes)

10. Re: Tx queueing (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 18 May 2000 22:17:51 -0400 (EDT)
Am i overposting? yikes. Should have read everything first. Jes Sorensen has probably got the cleanest interface i have seen. Look at the acenic driver. cheers, jamal
/archives/netdev/2000-05/msg00072.html (8,806 bytes)

11. Re: Tx queueing (score: 1)
Author: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Fri, 19 May 2000 11:16:08 +0800
Could you share your code? I would like to implement it finally in the mainstream kernel when I get time. Your code may help to save a few brain-cycles :-) This problem is known for 2.3.99pre kernels
/archives/netdev/2000-05/msg00073.html (9,963 bytes)

12. Re: Tx queueing (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 19 May 2000 16:21:12 -0400
IMNSHO you should try the compatibility module at http://gtf.org/garzik/drivers/kcompat24/ It provides the necessary glue to port 2.3.x/2.4.0 drivers back to 2.2.x. Note that its still an early devel
/archives/netdev/2000-05/msg00077.html (11,221 bytes)

13. Re: Tx queueing (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 19 May 2000 16:15:47 -0400
Not only is it simple, it's wrong wrong wrong. The only exceptions are going to be older NICs which only support a single Tx packet buffer (3c501 is like this?). Andrew (or anyone else) -- do you kno
/archives/netdev/2000-05/msg00078.html (11,753 bytes)

14. Re: Tx queueing (score: 1)
Author: Hendrik Boom <hendrik@xxxxxxxxxxxxx>
Date: Fri, 19 May 2000 14:33:07 -0400 (EDT)
Actually, I find backwards conptibilityto be much better in Linux than in other OSes for the same hardware. I suspect no one is using OS upgrades as a tool for forcing purchase of new application so
/archives/netdev/2000-05/msg00079.html (8,646 bytes)

15. Re: Tx queueing (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 19 May 2000 18:02:41 -0400
Which ones? They need fixing.. If you do something like that, it seems like it should be dependent on certain thresholds, not necessarily occurring all the time. And you'd want to sync with the Tx re
/archives/netdev/2000-05/msg00082.html (9,422 bytes)

16. Re: Tx queueing (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 20 May 2000 10:17:09 +1000
3c50?.c. Probably others... I'm disinclined to change these: - They're slow anyway. - Increased possiblity of breaking them - Broken 2.2/kcompat24 compatibility I guess if you need more performance o
/archives/netdev/2000-05/msg00084.html (9,849 bytes)

17. Re: Tx queueing (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Fri, 19 May 2000 22:35:57 -0400 (EDT)
The drivers still "exist", even if your copy has been updated. We are not claiming that bad code can't be changed, just that it was bad code that replacing good. The 3c501 is never ready to transmit
/archives/netdev/2000-05/msg00087.html (12,642 bytes)

18. Re: Tx queueing (score: 1)
Author: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Sat, 20 May 2000 12:33:39 +0800
First of all, we may try to use hardware checksumming without NDA documentation :-) Andrey
/archives/netdev/2000-05/msg00089.html (9,510 bytes)

19. Re: Tx queueing (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sat, 20 May 2000 15:53:57 +1000
What I meant was, if the 2.2 driver did this: start_xmit() { dev->tbusy = 1; ... } and the 2.3 driver does this: start_xmit() { netif_stop_queue(); ... } then the simple #define obviously perserves c
/archives/netdev/2000-05/msg00094.html (10,591 bytes)

20. Re: Tx queueing (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Sat, 20 May 2000 13:30:48 -0400
I should note that drivers with the logic in question (start_xmit: stop... start if not full) caused transmit timeouts and other nasties when used in modern PCI drivers. That's why I consider such lo
/archives/netdev/2000-05/msg00104.html (9,437 bytes)


This search system is powered by Namazu