mirror of
https://github.com/Fishwaldo/Star64_linux.git
synced 2025-07-06 06:21:31 +00:00
tcp: switch rcv_rtt_est and rcvq_space to high resolution timestamps
Some devices or distributions use HZ=100 or HZ=250 TCP receive buffer autotuning has poor behavior caused by this choice. Since autotuning happens after 4 ms or 10 ms, short distance flows get their receive buffer tuned to a very high value, but after an initial period where it was frozen to (too small) initial value. With tp->tcp_mstamp introduction, we can switch to high resolution timestamps almost for free (at the expense of 8 additional bytes per TCP structure) Note that some TCP stacks use usec TCP timestamps where this patch makes even more sense : Many TCP flows have < 500 usec RTT. Hopefully this finer TS option can be standardized soon. Tested: HZ=100 kernel ./netperf -H lpaa24 -t TCP_RR -l 1000 -- -r 10000,10000 & Peer without patch : lpaa24:~# ss -tmi dst lpaa23 ... skmem:(r0,rb8388608,...) rcv_rtt:10 rcv_space:3210000 minrtt:0.017 Peer with the patch : lpaa23:~# ss -tmi dst lpaa24 ... skmem:(r0,rb428800,...) rcv_rtt:0.069 rcv_space:30000 minrtt:0.017 We can see saner RCVBUF, and more precise rcv_rtt information. Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
a6db50b81e
commit
645f4c6f2e
3 changed files with 24 additions and 18 deletions
|
@ -333,16 +333,16 @@ struct tcp_sock {
|
|||
|
||||
/* Receiver side RTT estimation */
|
||||
struct {
|
||||
u32 rtt;
|
||||
u32 seq;
|
||||
u32 time;
|
||||
u32 rtt_us;
|
||||
u32 seq;
|
||||
struct skb_mstamp time;
|
||||
} rcv_rtt_est;
|
||||
|
||||
/* Receiver queue space */
|
||||
struct {
|
||||
int space;
|
||||
u32 seq;
|
||||
u32 time;
|
||||
int space;
|
||||
u32 seq;
|
||||
struct skb_mstamp time;
|
||||
} rcvq_space;
|
||||
|
||||
/* TCP-specific MTU probe information. */
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue