Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*LLTX\s+and\s+netif_stop

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*LLTX\s+and\s+netif_stop_queue\s*$/: 52 ]

Total 52 documents matching your query.

1. Re: LLTX and netif_stop_queue (score: 1): Author: Eric Lemoine <eric.lemoine@xxxxxxxxx>; Date: Mon, 3 Jan 2005 00:30:31 +0100; Two (untested) patches implementing what I described above. The first pach (sch_generic.patch) keeps queue_lock held in qdisc_restart() when calling hard_start_xmit() of a LLTX driver. The second (su; /archives/netdev/2005-01/msg00025.html (12,033 bytes)
2. Re: LLTX and netif_stop_queue (score: 1): Author: Eric Lemoine <eric.lemoine@xxxxxxxxx>; Date: Mon, 3 Jan 2005 08:41:40 +0100; Correction: the current LLTX drivers need not be modified to work correctly. However, as an opimisation, they can modified along sungem.patch's line. Thanks, -- Eric; /archives/netdev/2005-01/msg00026.html (10,896 bytes)
3. Re: LLTX and netif_stop_queue (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 03 Jan 2005 10:04:21 -0500; this piece: + + /* And release queue */ + spin_unlock(&dev->queue_lock); } -- Isnt there a possibility (higher as you increase number of processors) that you will spin for a long time in _the driver_; /archives/netdev/2005-01/msg00034.html (12,559 bytes)
4. Re: LLTX and netif_stop_queue (score: 1): Author: Eric Lemoine <eric.lemoine@xxxxxxxxx>; Date: Mon, 3 Jan 2005 16:48:00 +0100; I don't see how LLTX is different from non-LLTX wrt the time spent spinning on queue_lock. What am i missing? I do not like LLTX too much either as I can't see a cleaner way to get rid of that packet; /archives/netdev/2005-01/msg00035.html (11,744 bytes)
5. Re: LLTX and netif_stop_queue (score: 1): Author: Roland Dreier <roland@xxxxxxxxxxx>; Date: Mon, 03 Jan 2005 07:57:14 -0800; jamal> analysis of LLTX (with anything other than loopback) and jamal> shown it has any value? Maybe time to just shoot the damn jamal> thing. For the IPoIB driver, it seems to be worth a couple per; /archives/netdev/2005-01/msg00037.html (10,846 bytes)
6. Re: LLTX and netif_stop_queue (score: 1): Author: Eric Lemoine <eric.lemoine@xxxxxxxxx>; Date: Mon, 3 Jan 2005 17:41:05 +0100; What are your machines? In particular, how many CPUs do they have? -- Eric; /archives/netdev/2005-01/msg00039.html (11,683 bytes)
7. Re: LLTX and netif_stop_queue (score: 1): Author: Roland Dreier <roland@xxxxxxxxxxx>; Date: Mon, 03 Jan 2005 08:54:59 -0800; Dual Xeons with HT on, so they look like 4 CPUs. - R.; /archives/netdev/2005-01/msg00041.html (10,674 bytes)
8. Re: LLTX and netif_stop_queue (score: 1): Author: Eric Lemoine <eric.lemoine@xxxxxxxxx>; Date: Mon, 3 Jan 2005 18:07:00 +0100; If I understand correctly, LLTX aims at avoiding cache misses on lock variables (because of cacheline bouncing). So the effect of LLTX should increase as the number of CPUs not sharing the same cache; /archives/netdev/2005-01/msg00042.html (11,571 bytes)
9. m1 FIONREAD breakge (score: 1): Author: mminger@xxxxxxxx>; Date: Fri, 17 Dec 2004 13:57:40 -0800; ioctl-cleanups-broke-fionread-et-al 2004-12-13 11:12:37.687951760 -0800 +++ 25-akpm/fs/ioctl.c 2004-12-13 11:12:37.690951304 -0800 @@ -91,10 +91,8 @@ asmlinkag; /archives/netdev/2004-12/msg00474.html (10,811 bytes)
10. : possible cleanups (score: 1): Author: rnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>; Date: Fri, 17 Dec 2004 21:44:32 -0800; at 11:59:49PM -0200, Arnaldo Carvalho de Melo wrote: Adrian Bunk wrote: The patch below contans the following possible cleanups: - make some needlessly global; /archives/netdev/2004-12/msg00482.html (9,677 bytes)
11. user data in kernel (score: 1): Author: xxxxxx>; Date: Sat, 18 Dec 2004 07:35:49 -0800; nimum. Right. And you can get rid of /dev/mem if you don't want to screw yourself this way (which is well-known). The problem at hand is _not_ in this same lea; /archives/netdev/2004-12/msg00492.html (10,548 bytes)
12. 90: network driver. (score: 1): Author: n Bunk <bunk@xxxxxxxxx>; Date: 19 Dec 2004 14:31:15 -0500; illing to provide a sample program that hangs? Not too bad except user space doesnt get async notification. Ok, thats something you need to change. Why you are; /archives/netdev/2004-12/msg00509.html (9,607 bytes)
13. nd netif_stop_queue (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 19 Dec 2004 14:33:55 -0500; . Why you are; /archives/netdev/2004-12/msg00510.html (10,024 bytes)
14. nd netif_stop_queue (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 19 Dec 2004 14:54:51 -0500; ck is grabbed? That should bring it to par with what it was originally. cheers, jamal; /archives/netdev/2004-12/msg00511.html (10,264 bytes)
15. nd netif_stop_queue (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 19 Dec 2004 15:02:24 -0500; ne showing how to do it for e1000. untested (not even compiled) cheers, jamal Attachment: p1 Description: Text document Attachment: p2 Description: Text docume; /archives/netdev/2004-12/msg00512.html (10,424 bytes)
16. 90: network driver. (score: 1): Author: Tommy Christensen <tommy.christensen@xxxxxxxxx>; Date: Sun, 19 Dec 2004 14:35:26 -0800; , Thomas Spatzier wrote: jamal <hadi@xxxxxxxxxx> wrote on 15.12.2004 14:50:27: When you netif_stop_queue you should never receive packets anymore at the device; /archives/netdev/2004-12/msg00521.html (10,061 bytes)
17. 90: network driver. (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 19 Dec 2004 18:06:32 -0500; ions? If you wish to block while waiting for send, then you should be allowed. For a routing protocol that actually is notified that the link went down, it sho; /archives/netdev/2004-12/msg00526.html (10,456 bytes)
18. nd netif_stop_queue (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Sun, 19 Dec 2004 15:16:58 -0800; protocol that actually is notified that the link went down, it sho; /archives/netdev/2004-12/msg00527.html (10,748 bytes)
19. nel (slow socket?). (score: 1): Author: Matt Mackall <mpm@xxxxxxxxxxx>; Date: Wed, 22 Dec 2004 19:49:48 +0100; trying to achieve a faster L3 handoff on a wireless network. Right now it seems like one of the biggest bottlenecks is in the kernel. After I change IP addres; /archives/netdev/2004-12/msg00631.html (11,303 bytes)
20. ilure on HP 16-way) (score: 1): Author: ic Lemoine <eric.lemoine@xxxxxxxxx>; Date: Wed, 22 Dec 2004 20:29:19 -0800; similar should be applied, I think the underlying cause of tg3_readphy() returning error should be further investigated. Peter, if you provide more informatio; /archives/netdev/2004-12/msg00633.html (10,088 bytes)

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