tcp: rack pacing has some caveats that need to be obeyed when LRO is missing

n further non-LRO testing I found a case where rack is supposed to be waking up but
it is not now. In this special case it sets the flag rc_ack_can_sendout_data. When that is
set we should not prohibit output.

Reviewed by: tuexen
Sponsored by: Netflix Inc
Differential Revision:https://reviews.freebsd.org/D39565
This commit is contained in:
Randall Stewart 2023-04-14 09:33:36 -04:00
parent f97802a35e
commit 9903bf34f0

View File

@ -11578,7 +11578,7 @@ rack_log_hybrid(struct tcp_rack *rack, uint32_t seq,
log.u_bbr.lt_epoch = (uint32_t)((cur->deadline >> 32) & 0x00000000ffffffff) ;
log.u_bbr.bbr_state = 1;
off = (uint64_t)(cur) - (uint64_t)(&rack->rc_tp->t_http_info[0]);
log.u_bbr.bbr_substate = (uint8_t)(off / sizeof(struct http_sendfile_track));
log.u_bbr.use_lt_bw = (uint8_t)(off / sizeof(struct http_sendfile_track));
} else {
log.u_bbr.flex2 = err;
}
@ -16493,6 +16493,7 @@ rack_do_segment_nounlock(struct tcpcb *tp, struct mbuf *m, struct tcphdr *th,
*/
us_cts = tcp_tv_to_usectick(tv);
if ((rack->rc_always_pace == 1) &&
(rack->rc_ack_can_sendout_data == 0) &&
(rack->r_ctl.rc_hpts_flags & PACE_PKT_OUTPUT) &&
(TSTMP_LT(us_cts, rack->r_ctl.rc_last_output_to))) {
/*