|To:||Tommy Christensen <tommy.christensen@xxxxxxxxx>|
|Subject:||Re: [patch 4/10] s390: network driver.|
|From:||Jeff Garzik <jgarzik@xxxxxxxxx>|
|Date:||Mon, 20 Dec 2004 20:19:42 -0500|
|Cc:||hadi@xxxxxxxxxx, Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Hasso Tepper <hasso@xxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Paul Jakma <paul@xxxxxxxx>|
|References:||<OF28701C56.81E1D26E-ONC1256F6B.00513EDD-C1256F6B.0052AF84@xxxxxxxxxx> <1103484552.1046.155.camel@xxxxxxxxxxxxxxxx> <41C600D7.70005@xxxxxxxxx> <1103497516.1046.231.camel@xxxxxxxxxxxxxxxx> <41C612BC.5070909@xxxxxxxxx> <1103551830.1047.316.camel@xxxxxxxxxxxxxxxx> <41C71FFD.7090308@xxxxxxxxx> <41C76AA0.7020800@xxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922|
Tommy Christensen wrote:
Jeff Garzik wrote:I haven't heard anything to convince me that the same change should be deployed across NNN drivers. The drivers already signal the net core that the link is down; to me, that implies there should be code in _one_ place that handles this condition, not NNN places.AFAICS only a handful of (newer) drivers call netif_stop_queue() directly. Others may do this indirectly if the MAC stops taking packets from the DMA ringbuffer. At least some MAC's/drivers certainly don't.
Incorrect. Use of netif_stop_queue() is -required- to signal that the hardware cannot accept any more skbs from the system.
Far more than a "handful" and required for all but a few very strange drivers.
OK, another view on this: isn't is problematic to have skb's stuck in the network stack "indefinitely" ? They hold references to a dst_entry and a sock (and probably more). So how about this for the FAQ: Q: Why can't I unload the af_packet module? A: Ohh, you'll have to plug in the darn cable to eth0 first! *Please* tell me, I've got this all wrong.
You've got this all wrong. Jeff
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way), Peter Chubb|
|Next by Date:||Re: TG3 fix for slow switches (Was: TG3 driver failure on HP 16-way), David S. Miller|
|Previous by Thread:||Re: [patch 4/10] s390: network driver., Tommy Christensen|
|Next by Thread:||Re: [patch 4/10] s390: network driver., Thomas Spatzier|
|Indexes:||[Date] [Thread] [Top] [All Lists]|