|Subject:||Re: on the wire behaviour of TSO on/off is supposed to be the same yes?|
|From:||Rick Jones <rick.jones2@xxxxxx>|
|Date:||Fri, 21 Jan 2005 14:48:08 -0800|
|References:||<41F1516D.email@example.com> <firstname.lastname@example.org> <41F163AD.email@example.com> <firstname.lastname@example.org> <41F17B7E.email@example.com> <firstname.lastname@example.org>|
|User-agent:||Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.7.3) Gecko/20041206|
David S. Miller wrote:
On Fri, 21 Jan 2005 14:00:30 -0800 Rick Jones <rick.jones2@xxxxxx> wrote:
Ah, _that_ explains why in so many of my traces it stays at one value for sooo long. And in some places it seemed to jump by fairly large quantities. I thought it was related to the window size, but in a netperf TCP_STREAM test, unless the sender sets the -m option, it is set based on the getsockopt() that follows the setsockopt() from the -s, and since -S was 128K, and since Linux doubles that on the getsockopt().... that explains the O(200K) bit before > 1448 byte sends when the divisor was set to 8.
That's an interesting observation actually, thanks for showing it.
It means that ideally we might want to try and find a way to either:
Indeed, it seems that one would want to decide about TSO when one is about to transmit, not when the user does a send since otherwise, you penalize users doing larger sends. Someone doing say a sendfile() of a large file would be pretty much precluded from getting benefit from TSO the way things are now right?
(There is a netperf TCP_SENDFILE test, but it defaults the send size to the socket buffer size just like TCP_STREAM)
And I suspect that is the case for some of the (un)spoken workloads of interest among the system vendors. That's not to say that we still won't have incentive to set tcp_tso_win_divisor (shouldn't that really be tcp_tso_cwnd_divisor?) to 1 :) I suspect we will still want that initial "4380" cwnd bytes to be a single TSO transmission... every cycle's sacred, every cycle's great... :)
BTW, has the whole "reply-to" question already been thrashed about on this list? Is it an open or closed list? I ask because I keep getting two copies of everyone's replies - one to me, one to the list... just a nit...
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [XFRM] Probe selected algorithm only, Herbert Xu|
|Next by Date:||Re: [RFC 2.6.10 3/22] xfrm: Add offload management routines, David S. Miller|
|Previous by Thread:||Re: on the wire behaviour of TSO on/off is supposed to be the same yes?, David S. Miller|
|Next by Thread:||Re: on the wire behaviour of TSO on/off is supposed to be the same yes?, Rick Jones|
|Indexes:||[Date] [Thread] [Top] [All Lists]|