diff options
| author | Randall Stewart <rrs@FreeBSD.org> | 2021-12-15 14:41:33 +0000 |
|---|---|---|
| committer | Randall Stewart <rrs@FreeBSD.org> | 2021-12-15 14:41:33 +0000 |
| commit | 9b602965311391f495f4edff246bcb1de5269bbb (patch) | |
| tree | 7b35c3b7cf86209a35ffd0d705148a11268c522a | |
| parent | 9935b0e8ea41804b32576987531be4d31ba705f1 (diff) | |
| download | src-9b602965311391f495f4edff246bcb1de5269bbb.tar.gz src-9b602965311391f495f4edff246bcb1de5269bbb.zip | |
tcp: Rack in a rare case we can get stuck sending a very small amount.
If a tlp sending new data fails, and then the peer starts
talking to us again, we can be in a situation where the
tlp_new_data count is set, we are not in recovery and
we always send one packet every RTT. The failure
has to occur when we send the TLP initially from the ip_output()
which is rare. But if it occurs you are basically stuck.
This fixes it so we use the new_data count and clear it so
we know it will be cleared. If a failure occurs the tlp timer
will regenerate a new amount anyway so it is un-needed to
carry the value on.
Reviewed by: Michael Tuexen
Sponsored by: Netflix Inc.
Differential Revision: https://reviews.freebsd.org/D33325
| -rw-r--r-- | sys/netinet/tcp_stacks/rack.c | 5 |
1 files changed, 1 insertions, 4 deletions
diff --git a/sys/netinet/tcp_stacks/rack.c b/sys/netinet/tcp_stacks/rack.c index 16faa887530f..202829f12b7c 100644 --- a/sys/netinet/tcp_stacks/rack.c +++ b/sys/netinet/tcp_stacks/rack.c @@ -17329,6 +17329,7 @@ again: } else { len = rack->r_ctl.rc_tlp_new_data; } + rack->r_ctl.rc_tlp_new_data = 0; } else { len = rack_what_can_we_send(tp, rack, cwnd_to_use, avail, sb_offset); } @@ -18972,10 +18973,6 @@ out: rack->rc_gp_saw_ss = 1; } } - if (doing_tlp && (rsm == NULL)) { - /* Make sure new data TLP cnt is clear */ - rack->r_ctl.rc_tlp_new_data = 0; - } if (TCPS_HAVEESTABLISHED(tp->t_state) && (tp->t_flags & TF_SACK_PERMIT) && tp->rcv_numsacks > 0) |