Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Queue\s+and\s+SMP\s+locking\s+discussion\s+$was\s+Re\:\s+3c59x\.c$\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Queue\s+and\s+SMP\s+locking\s+discussion\s+$was\s+Re\:\s+3c59x\.c$\s*$/: 42 ]

Total 42 documents matching your query.

1. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Sat, 1 Apr 2000 15:27:10 +0200; Interesting is that Intel's driver also shows how to use RX hardware checksums (although they use a very ugly way to implement it with CHECKSUM_NONE, instead of using CHECKSUM_HW). Unfortunately my e; /archives/netdev/2000-04/msg00003.html (9,768 bytes)
2. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Sat, 1 Apr 2000 10:28:25 -0500 (EST); Michael, I think we had this debate during your presentation ;-> Here are my thoughts: Bus Latency is not a problem as far as throughput is concerned. This problem can be equated to *exactly* the hig; /archives/netdev/2000-04/msg00004.html (9,615 bytes)
3. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: Donald Becker <becker@xxxxxxxxx>; Date: Sat, 1 Apr 2000 12:30:48 -0500 (EST); ... This is a very important point: the Tulip hardware and driver in 2.0 and 2.2 can easily handle the worst a 100baseTx link can throw at it. Just queuing the packet in netif_rx() *should* take mini; /archives/netdev/2000-04/msg00008.html (9,042 bytes)
4. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Sun, 2 Apr 2000 11:02:00 +0200 (CEST); If you have a flexible packet generator and are testing the routing path you can mark the packets when sending it - And just count the marked packets in the receiver end. And instead of passing them; /archives/netdev/2000-04/msg00010.html (9,143 bytes)
5. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: kuznet@xxxxxxxxxxxxx; Date: Sun, 2 Apr 2000 20:34:18 +0400 (MSK DST); It is true, it does not take any time. But we need not this. We need to do some work in the worst conditions, rather then to serve as perfect blackhole. Linux as it is, is perfect blackhole. We need; /archives/netdev/2000-04/msg00015.html (8,913 bytes)
6. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Mon, 3 Apr 2000 07:12:31 -0400 (EDT); Sorry it was 148 kpps and not 150Kpps (which is beyond the 100Mbps spec). I have a 21143 -- is that what you mean by Genuine? Thanks. Alexey pointed me to your extension a few months back. What kind; /archives/netdev/2000-04/msg00020.html (9,136 bytes)
7. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Mon, 3 Apr 2000 07:21:59 -0400 (EDT); Looking at my notes: 2.3 just swallows as much as 2.2. Maybe this is chip dependent as Robert was implying? I have a 21143 chip. I should easily be able to check the exact revision numbers from the P; /archives/netdev/2000-04/msg00021.html (8,722 bytes)
8. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Mon, 3 Apr 2000 15:39:08 +0200 (CEST); Not at all! We did a lot experimenting with this about 2 years ago. New ideas came every day most of them came from Russia. :-) between two tulip NIC's and smallest packets 64 bytes. (PII ~400 Mhz ~1; /archives/netdev/2000-04/msg00025.html (9,554 bytes)
9. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: Michael Richardson <mcr@xxxxxxxxxxx>; Date: Mon, 03 Apr 2000 14:29:08 -0400; jamal> I think we had this debate during your presentation ;-> Here are jamal> my thoughts: jamal> Bus Latency is not a problem as far as throughput is jamal> concerned. This problem can be equated; /archives/netdev/2000-04/msg00029.html (10,505 bytes)
10. Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxxx; Date: Thu, 30 Mar 2000 14:55:26 -0500 (EST); .. Look at the note in net_init.c, which I created to replace Space.c. For those that don't get the reference "pl14" refers to kernel 0.99pl14, i.e. 0.0.99-pre14 ! Once an bad interface is put into p; /archives/netdev/2000-03/msg00069.html (15,901 bytes)
11. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Thu, 30 Mar 2000 15:48:10 -0500 (EST); Donald, I am to blame for that -- as is stated in the document disclaimer. Here's the reasoning: In my analysis i noted that the "tx timeout" problems under moderate network loads was _mostly_ becaus; /archives/netdev/2000-03/msg00070.html (10,927 bytes)
12. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 02:27:50 +0000; I believe that this tx starvation is due to the decision to schedule the tx in the device ISR, for BH handling, rather than to actually dequeue and send packets within the Tx ISR. I can see why the b; /archives/netdev/2000-03/msg00073.html (11,308 bytes)
13. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 02:43:36 +0000; Spit. I missed the test_and_set_bit(__LINK_STATE_XOFF... I still question it though: status = inw(ioaddr + EL3_STATUS); do { ... if (status & TxAvailable) { outw(AckIntr | TxAvailable, ioaddr + EL3_C; /archives/netdev/2000-03/msg00074.html (10,250 bytes)
14. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 12:51:30 +0200 (MET DST); Or maybe we could adapt "War" by Bruce Springsteen: "Space.c ! UH ! What is it good for ? Absolutely nothin' !" Considering all the hairy locking issues and that there seems to be a general trend of; /archives/netdev/2000-03/msg00075.html (12,999 bytes)
15. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 08:55:53 -0500 (EST); loop-until-max_interrupt_work-exceeded will *not* help you in this. Packet arrivals still mean interupts. Mitigation (which seems to be added to some of Donalds drivers by Jeff Garzik and Andrey Savo; /archives/netdev/2000-03/msg00076.html (10,353 bytes)
16. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 10:08:00 -0500 (EST); Not only is the Linux scheme simpler, it's much better. The BSD stack uses the scheme of dequeuing packets in the ISR. This was a good design in the VAX days, and with primative hardware that handled; /archives/netdev/2000-03/msg00077.html (12,186 bytes)
17. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 11:16:56 -0500 (EST); It does limit the work done by a specific subsystem so that other devices on the same IRQ chain can do their work. At the end of the handler scan the interrupt dispatch system a chance to run other I; /archives/netdev/2000-03/msg00078.html (11,875 bytes)
18. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 21:57:56 +0400 (MSK DST); Donald, I do not understand you, honestly. Design better scheme. Just do it. If you have no time to do it, you will have to work in environment, designed by stupid guys sort of me, who always have l; /archives/netdev/2000-03/msg00079.html (11,566 bytes)
19. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxxx; Date: Fri, 31 Mar 2000 22:46:15 +0400 (MSK DST); Well, do not stop queue, then there will be no reasons to wake it. If we stop queue, we have to wake it. Khm... Please, get some simple benchmark applet sort of netperf and enjoy with this impossibl; /archives/netdev/2000-03/msg00080.html (10,311 bytes)
20. Re: Queue and SMP locking discussion (was Re: 3c59x.c) (score: 1): Author: xxxxxx>; Date: Fri, 31 Mar 2000 14:08:19 -0500; kuznet> Khm... Please, get some simple benchmark applet sort of netperf kuznet> and enjoy with this impossible phenomenon on single 100Mbit kuznet> interface. Despite of all the "max job on interrup; /archives/netdev/2000-03/msg00082.html (10,982 bytes)

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