Messages in this thread | | | From | Neal Cardwell <> | Date | Wed, 3 Jun 2020 08:02:13 -0400 | Subject | Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode |
| |
On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet <edumazet@google.com> wrote: > > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing <kerneljasonxing@gmail.com> wrote: > > > > Hi Eric, > > > > I'm still trying to understand what you're saying before. Would this > > be better as following: > > 1) discard the tcp_internal_pacing() function. > > 2) remove where the tcp_internal_pacing() is called in the > > __tcp_transmit_skb() function. > > > > If we do so, we could avoid 'too late to give up pacing'. Meanwhile, > > should we introduce the tcp_wstamp_ns socket field as commit > > (864e5c090749) does? > > > > Please do not top-post on netdev mailing list. > > > I basically suggested double-checking which point in TCP could end up > calling tcp_internal_pacing() > while the timer was already armed. > > I guess this is mtu probing.
Perhaps this could also happen from some of the retransmission code paths that don't use tcp_xmit_retransmit_queue()? Perhaps tcp_retransmit_timer() (RTO) and tcp_send_loss_probe() TLP? It seems they could indirectly cause a call to __tcp_transmit_skb() and thus tcp_internal_pacing() without first checking if the pacing timer was already armed?
neal
| |