Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[patch\s+4\/10\]\s+s390\:\s+network\s+driver\.\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[patch\s+4\/10\]\s+s390\:\s+network\s+driver\.\s*$/: 132 ]

Total 132 documents matching your query.

121. Re: [patch 4/10] s390: network driver. (score: 1): Author: Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>; Date: Wed, 22 Dec 2004 11:56:06 +0100; Jeff Garzik <jgarzik@xxxxxxxxx> wrote on 20.12.2004 19:54:53: This sounds plausible and I'm with Jeff here. For me as the driver author it's the smallest change. I will put it like this: on cable gon; /archives/netdev/2004-12/msg01565.html (10,788 bytes)
122. Re: [patch 4/10] s390: network driver. (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Wed, 22 Dec 2004 06:07:52 -0500; Side note to all driver authors, make sure you only ever start or wake the queue if there is truly space available for another skb. Jeff; /archives/netdev/2004-12/msg01566.html (10,574 bytes)
123. Re: [patch 4/10] s390: network driver. (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 22 Dec 2004 08:48:28 -0500; I think this needs to be resolved too. It is possible to have a centralized action instead of requiring drivers to make changes if we know the state of the driver is in netcarrier_off. What that woul; /archives/netdev/2004-12/msg01573.html (11,135 bytes)
124. Re: [patch 4/10] s390: network driver. (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Sun, 26 Dec 2004 16:36:23 +1100; Please show us your program first. Then we can figure out whether this is necessary or not. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Ho; /archives/netdev/2004-12/msg01616.html (10,089 bytes)
125. Re: [patch 4/10] s390: network driver. (score: 1): Author: Jeff Garzik <jgarzik@xxxxxxxxx>; Date: Sat, 13 Nov 2004 20:29:13 -0500; You should be using netif_carrier_{on,off} properly, and not drop the packets. When (if) link comes back, you requeue the packets to hardware (or hypervisor or whatever). Your dev->stop() should sto; /archives/netdev/2004-11/msg01543.html (10,257 bytes)
126. Re: [patch 4/10] s390: network driver. (score: 1): Author: Paul Jakma <paul@xxxxxxxx>; Date: Mon, 15 Nov 2004 07:52:50 +0000 (GMT); Queues are DESIGNED to fill up under various conditions. What happens when they are full? Blocking isnt good, at least not from GNU Zebra / Quagga's POV. Would not the zebra routing software have th; /archives/netdev/2004-11/msg01593.html (10,946 bytes)
127. Re: [patch 4/10] s390: network driver. (score: 1): Author: Paul Jakma <paul@xxxxxxxx>; Date: Sun, 21 Nov 2004 08:16:34 +0000 (GMT); non-raw/header-included sockets, eg BGP tcp sockets, a user like GNU Zebra / Quagga would much prefer packets to be dropped. Ur... not for TCP.. obviously. Anyway, is there any advice on how applicat; /archives/netdev/2004-11/msg01817.html (10,096 bytes)
128. Re: [patch 4/10] s390: network driver. (score: 1): Author: Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>; Date: Mon, 29 Nov 2004 16:57:25 +0100; I do also think that it does not make sense to keep packets in the queue and then send those packets when the cable is plugged in again after a possibly long time. There are protocols like TCP that; /archives/netdev/2004-11/msg02038.html (8,671 bytes)
129. Re: [patch 4/10] s390: network driver. (score: 1): Author: Paul Jakma <paul@xxxxxxxx>; Date: Mon, 29 Nov 2004 16:30:23 +0000 (GMT); Has there been any outcome on the discussion about whether or not a device driver should drop packets when the cable is disconnected? There hasnt. It seems that from the zebra point of view, as Paul; /archives/netdev/2004-11/msg02040.html (11,521 bytes)
130. Re: [patch 4/10] s390: network driver. (score: 1): Author: Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>; Date: Mon, 29 Nov 2004 17:41:42 +0100; Paul Jakma <paul@xxxxxxxx> wrote on 29.11.2004 17:30:23: Yes, for the examples you mentioned the app should better be notified. However, AFAICS, there are no such notification mechanisms on a per-pac; /archives/netdev/2004-11/msg02041.html (9,178 bytes)
131. Re: [patch 4/10] s390: network driver. (score: 1): Author: Paul Jakma <paul@xxxxxxxx>; Date: Mon, 29 Nov 2004 20:27:57 +0000 (GMT); Yes, for the examples you mentioned the app should better be notified. However, AFAICS, there are no such notification mechanisms on a per-packet basis implemented in the kernel. And I doubt that the; /archives/netdev/2004-11/msg02051.html (11,064 bytes)
132. Re: [patch 4/10] s390: network driver. (score: 1): Author: Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>; Date: Tue, 30 Nov 2004 08:22:01 +0100; Paul Jakma <paul@xxxxxxxx> wrote on 29.11.2004 21:27:57: Ok, then some logic could be implemented in userland to take appropriate actions. It must be ensured that zebra handles the netlink notificati; /archives/netdev/2004-11/msg02069.html (9,867 bytes)

Current List: 121 - 132
Page: [1] [2] [3] [4] [5] [6] [7]