| To: | Jeff Garzik <jgarzik@xxxxxxxxx> |
|---|---|
| Subject: | Re: [patch 4/10] s390: network driver. |
| From: | Paul Jakma <paul@xxxxxxxx> |
| Date: | Wed, 5 Jan 2005 06:26:32 +0000 (GMT) |
| Cc: | hadi@xxxxxxxxxx, Thomas Spatzier <thomas.spatzier@xxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, Hasso Tepper <hasso@xxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Tommy Christensen <tommy.christensen@xxxxxxxxx> |
| In-reply-to: | <41DB26A6.2070008@pobox.com> |
| Mail-followup-to: | paul@xxxxxxxxxxxxxxxxxx |
| References: | <OFB7F7E23F.EFB88418-ONC1256F7E.0031769E-C1256F7E.003270AD@de.ibm.com> <1104764710.1048.580.camel@jzny.localdomain> <41DB26A6.2070008@pobox.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Tue, 4 Jan 2005, Jeff Garzik wrote: Aren't there cases where people would -not- want the queue to be cleared? Why *do* you want the queue to be cleared? (avoiding NIC /dev/null is only reason right?) TCP (AIUI) has its owns means to resend. Most (all?) other transports have *never* had an expectation of such reliability. Applications *know* they have to provide their own reliability. Queueing and later sending (by then) stale packets is *bad* Think: - heartbeat applications - Router or route advertisements (IPv6 RA, IPv4 ICMP IRDP, RIP) - Streaming media (ok, not much damage here, but still there's simply no point queueing while link is down..) Why queue packets on behalf of applications which have no expectation of kernel doing this (any application expecting such is certainlty broken) and which very likely implement their own reliability or packet-loss recovery strategies? Particularly when queueing is quite possibly *detrimental* to what the application is trying to achieve (timely sending of packets). If an application wants reliable sending of packets, it will be using TCP.. Jeff
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [patch 1/1] ixgb LR card support, akpm |
|---|---|
| Next by Date: | Re: [patch 4/10] s390: network driver., Paul Jakma |
| Previous by Thread: | Re: [patch 4/10] s390: network driver., Tommy Christensen |
| Next by Thread: | [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier, Thomas Graf |
| Indexes: | [Date] [Thread] [Top] [All Lists] |