|To:||"David S. Miller" <davem@xxxxxxxxxx>|
|Subject:||Re: RFC: per-socket statistics on received/dropped packets|
|From:||Lincoln Dale <ltd@xxxxxxxxx>|
|Date:||Mon, 10 Jun 2002 22:03:25 +1000|
|Cc:||greearb@xxxxxxxxxxxxxxx, mark@xxxxxxxxxxxxxx, cfriesen@xxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx|
|References:||<3D039D22.2010805@xxxxxxxxxxxxxxx> <3D029DAF.5040006@xxxxxxxxxxxxxxx> <20020608.175108.84748597.davem@xxxxxxxxxx> <3D039D22.2010805@xxxxxxxxxxxxxxx>|
At 09:34 PM 9/06/2002 -0700, David S. Miller wrote:
Every argument I hear is one out of lazyness. And that is not a reason to add something. Simply put, I don't want to add all of this per-socket counter bumping that only, at best, 1 tenth of 1 percent of people will use. This means that the rest of the world eats the overhead just for this small group that actually uses it.
would you be willing to accept a patch that enables per-socket accounting with a CONFIG_ option?
to my mind, i can see a number of perfectly valid scenarios.one is for streaming-media applications which could use retransmissions as an indication to buffer more data and/or switch to a different bitrate.
another is for a http proxy which has multiple outgoing interfaces which are multihomed via different providers (and some via simplex satellite). retransmissions woud be a nice metric to use for determining the weightings between using different interfaces.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: Network oops, David S. Miller|
|Next by Date:||Re: RFC: per-socket statistics on received/dropped packets, David S. Miller|
|Previous by Thread:||Re: RFC: per-socket statistics on received/dropped packets, Ben Greear|
|Next by Thread:||Re: RFC: per-socket statistics on received/dropped packets, David S. Miller|
|Indexes:||[Date] [Thread] [Top] [All Lists]|