From: Eric Dumazet <eric.dumazet@gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: David Miller <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Yuchung Cheng <ycheng@google.com>, Van Jacobson <vanj@google.com>,
Tom Herbert <therbert@google.com>
Subject: Re: [PATCH net-next] tcp: TSO packets automatic sizing
Date: Sat, 24 Aug 2013 13:28:00 -0700 [thread overview]
Message-ID: <1377376080.8828.83.camel@edumazet-glaptop> (raw)
In-Reply-To: <1377370594.8828.72.camel@edumazet-glaptop>
On Sat, 2013-08-24 at 11:56 -0700, Eric Dumazet wrote:
> Problem is that if the application does a sendmsg( 1 Mbytes) right after
> accept(), we'll cook 14KB TSO packets and are back to initial problem.
>
> Quite frankly TSO advantage for servers sending replies that are 10MSS
> or less is thin, because we spend most of cpu cycles in socket
> setup/dismantle and ACK processing.
>
> TSO is a win for sockets sending say more than 100KB, or even 1MB
Another interesting point having small packets at the beginning of the
connection when/if pacing is enabled in the (FQ) packet scheduler,
an incorrect initial rtt would have lower impact :
13:14:45.271930 IP 10.246.17.83.41052 > 10.246.17.84.41129: S 2688061178:2688061178(0) win 29200 <mss 1460,sackOK,timestamp 281602 0,nop,wscale 6>
13:14:45.322055 IP 10.246.17.84.41129 > 10.246.17.83.41052: S 1339982632:1339982632(0) ack 2688061179 win 28960 <mss 1460,sackOK,timestamp 146299869 281602,nop,wscale 7>
13:14:45.322126 IP 10.246.17.83.41052 > 10.246.17.84.41129: . ack 1 win 457 <nop,nop,timestamp 281652 146299869>
13:14:45.322245 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 1:1449(1448) ack 1 win 457 <nop,nop,timestamp 281652 146299869>
13:14:45.324944 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 1449:2897(1448) ack 1 win 457 <nop,nop,timestamp 281652 146299869>
13:14:45.327600 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 2897:4345(1448) ack 1 win 457 <nop,nop,timestamp 281652 146299869>
13:14:45.330301 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 4345:5793(1448) ack 1 win 457 <nop,nop,timestamp 281652 146299869>
13:14:45.333001 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 5793:7241(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.335697 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 7241:8689(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.338392 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 8689:10137(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.341087 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 10137:11585(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.343770 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 11585:13033(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.346471 IP 10.246.17.83.41052 > 10.246.17.84.41129: . 13033:14481(1448) ack 1 win 457 <nop,nop,timestamp 281653 146299869>
13:14:45.372577 IP 10.246.17.84.41129 > 10.246.17.83.41052: . ack 1449 win 249 <nop,nop,timestamp 146299919 281652>
If the "ack 1449" coming back from client was coming sooner than expected,
this could change the srtt estimation and packet scheduler could
send remaining packets sooner.
This makes me think that srtt computation could be more precise.
First RTT sample sets SRTT=RTT
But second sample sets to SRTT = SRTT*7/8 + nRTT,
while it probably should do SRTT = (SRTT + nRTT)/2
Third sample also should do : SRTT = SRTT*2/3 + nRTT/3
...
next prev parent reply other threads:[~2013-08-24 20:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-24 0:29 [PATCH net-next] tcp: TSO packets automatic sizing Eric Dumazet
2013-08-24 3:17 ` Neal Cardwell
2013-08-24 18:56 ` Eric Dumazet
2013-08-24 20:28 ` Eric Dumazet [this message]
2013-08-25 22:01 ` Yuchung Cheng
2013-08-26 0:37 ` Eric Dumazet
2013-08-26 2:22 ` Eric Dumazet
2013-08-26 3:58 ` Eric Dumazet
2013-08-25 2:46 ` David Miller
2013-08-25 2:52 ` Eric Dumazet
2013-08-26 4:26 ` [PATCH v2 " Eric Dumazet
2013-08-26 19:09 ` Yuchung Cheng
2013-08-26 20:28 ` Eric Dumazet
2013-08-26 22:31 ` Yuchung Cheng
2013-08-27 0:47 ` Eric Dumazet
2013-08-27 12:46 ` [PATCH v3 " Eric Dumazet
2013-08-28 0:17 ` Yuchung Cheng
2013-08-28 0:21 ` Neal Cardwell
2013-08-28 7:37 ` Jason Wang
2013-08-28 10:34 ` Eric Dumazet
2013-08-30 3:02 ` Jason Wang
2013-08-29 19:51 ` David Miller
2013-08-29 20:26 ` Eric Dumazet
2013-08-29 20:35 ` David Miller
2013-08-29 21:26 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377376080.8828.83.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
--cc=vanj@google.com \
--cc=ycheng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox