d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

tcp: Rack in a rare case we can get stuck sending a very small amount.

Browse Source 
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
This commit is contained in:
Randall Stewart 2021-12-15 09:41:33 -05:00
parent 9935b0e8ea
commit 9b60296531
1 changed files with 1 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
sys/netinet/tcp_stacks/rack.c
View File

@ -17329,6 +17329,7 @@ rack_output(struct tcpcb *tp)
} 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 @@ rack_output(struct tcpcb *tp)
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)