On Fri, 26 Feb 2021 17:35:11 +0100 Eric Dumazet wrote:
> On Fri, Feb 26, 2021 at 5:09 PM Jakub Kicinski wrote:
> > On Fri, 26 Feb 2021 11:41:22 +0100 Eric Dumazet wrote:
> > > Yes, this packetdrill test confirms TCP INFO stuff seems correct .
> >
> > Looks like it's TcpExtTCPSpuriousRtxHostQue
On Fri, 26 Feb 2021 11:41:22 +0100 Eric Dumazet wrote:
> > > Seems like I'm pretty lost here and the tcp:tcp_retransmit_skb events
> > > are less spurious than I thought. Looking at some tcpdump traces we see:
> > >
> > > 0.045277 IP6 A > B: Flags [SEW], seq 2248382925:2248383296, win 61920,
> > >
On Fri, 26 Feb 2021 11:41:22 +0100 Eric Dumazet wrote:
> On Fri, Feb 26, 2021 at 11:05 AM Eric Dumazet wrote:
> >
> > On Fri, Feb 26, 2021 at 4:15 AM Jakub Kicinski wrote:
> > >
> > > On Thu, 25 Feb 2021 15:25:15 -0800 Jakub Kicinski wrote:
> > > > Hi!
> > > >
> > > > We see large (4-8x) incr
On Thu, 25 Feb 2021 15:25:15 -0800 Jakub Kicinski wrote:
> Hi!
>
> We see large (4-8x) increase of what looks like TCP RTOs after rising
> the Tx coalescing above Rx coalescing timeout.
>
> Quick tracing of the events seems to indicate that the data has already
> been acked when we enter tcp:tcp
Hi!
We see large (4-8x) increase of what looks like TCP RTOs after rising
the Tx coalescing above Rx coalescing timeout.
Quick tracing of the events seems to indicate that the data has already
been acked when we enter tcp:tcp_retransmit_skb:
sk_state: 1
icsk_ca_state: 4
bytes_in: 0
b
