On Fri, 26 Feb 2021 17:35:11 +0100 Eric Dumazet wrote: > On Fri, Feb 26, 2021 at 5:09 PM Jakub Kicinski <k...@kernel.org> 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 TcpExtTCPSpuriousRtxHostQueues - the TFO fails as it > > might, but at the time the syn is still not kfree_skb()d because of > > the IRQ coalescing settings, so __tcp_retransmit_skb() returns -EBUSY > > and we have to wait for a timeout. > > > > Credit to Neil Spring @FB for figuring it out. > > Yes, this makes sense. > > Presumably tcp_send_syn_data() could allocate a regular (non fclone) > skb, to avoid this. > > But if skb_still_in_host_queue() returns true, __tcp_retransmit_skb() > should return -EBUSY > and your tracepoint should not be called ?
Right, looking at the stack trace the call I was tracing comes later from the RTO timer. > In anycase, the bytes_acked should not be 742 as mentioned in your > email, if only the SYN was acked ? You're right, it's 1. I did a braino in the trace print yesterday.
