[Top] [All Lists]

Re: [patch 4/10] s390: network driver.

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@xxxxxxxxx>
Mail-followup-to: paul@xxxxxxxxxxxxxxxxxx
References: <OFB7F7E23F.EFB88418-ONC1256F7E.0031769E-C1256F7E.003270AD@xxxxxxxxxx> <1104764710.1048.580.camel@xxxxxxxxxxxxxxxx> <41DB26A6.2070008@xxxxxxxxx>
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*


- 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..


Paul Jakma      paul@xxxxxxxx   paul@xxxxxxxxx  Key ID: 64A2FF6A
When the speaker and he to whom he is speaks do not understand, that is
                -- Voltaire

<Prev in Thread] Current Thread [Next in Thread>