]> git.baikalelectronics.ru Git - kernel.git/commit
tcp: initialize passive-side sk_pacing_rate after 3WHS
authorNeal Cardwell <ncardwell@google.com>
Mon, 21 Oct 2013 19:40:19 +0000 (15:40 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 21 Oct 2013 22:56:23 +0000 (18:56 -0400)
commitfd01f52710a2a5050bad26e298da2820df8971a9
tree864cf11d0c85f96e897ab42b72535f19496accda
parentb23ed6b6ee9181cca259bab486b660f5713af701
tcp: initialize passive-side sk_pacing_rate after 3WHS

For passive TCP connections, upon receiving the ACK that completes the
3WHS, make sure we set our pacing rate after we get our first RTT
sample.

On passive TCP connections, when we receive the ACK completing the
3WHS we do not take an RTT sample in tcp_ack(), but rather in
tcp_synack_rtt_meas(). So upon receiving the ACK that completes the
3WHS, tcp_ack() leaves sk_pacing_rate at its initial value.

Originally the initial sk_pacing_rate value was 0, so passive-side
connections defaulted to sysctl_tcp_min_tso_segs (2 segs) in skbuffs
made in the first RTT. With a default initial cwnd of 10 packets, this
happened to be correct for RTTs 5ms or bigger, so it was hard to
see problems in WAN or emulated WAN testing.

Since bd28947686 ("pkt_sched: fq: fix non TCP flows pacing"), the
initial sk_pacing_rate is 0xffffffff. So after that change, passive
TCP connections were keeping this value (and using large numbers of
segments per skbuff) until receiving an ACK for data.

Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/tcp_input.c