From: Lawrence Brakmo <bra...@fb.com> Date: Tue, 3 Jul 2018 09:26:13 -0700
> When have observed high tail latencies when using DCTCP for RPCs as > compared to using Cubic. For example, in one setup there are 2 hosts > sending to a 3rd one, with each sender having 3 flows (1 stream, > 1 1MB back-to-back RPCs and 1 10KB back-to-back RPCs). The following > table shows the 99% and 99.9% latencies for both Cubic and dctcp: > > Cubic 99% Cubic 99.9% dctcp 99% dctcp 99.9% > 1MB RPCs 2.6ms 5.5ms 43ms 208ms > 10KB RPCs 1.1ms 1.3ms 53ms 212ms ... > v2: Removed call to tcp_ca_event from tcp_send_ack since I added one in > tcp_event_ack_sent. Based on Neal Cardwell <ncardw...@google.com> > feedback. > Modified tcp_ecn_check_ce (and renamed it tcp_ecn_check) instead of > modifying > tcp_ack_send_check to insure an ACK when cwr is received. > v3: Handling cwr in tcp_ecn_accept_cwr instead of in tcp_ecn_check. > > [PATCH net-next v3 1/2] tcp: notify when a delayed ack is sent > [PATCH net-next v3 2/2] tcp: ack immediately when a cwr packet Neal and co., what are your thoughts right now about this patch series? Thank you.
