On 2024-04-07 03:51, Menglong Dong wrote:On Sun, Apr 7, 2024 at 2:52 PM Jason Xing <kerneljasonxing(a)gmail.com> wrote: > On Sun, Apr 7, 2024 at 2:38 AM Eric Dumazet <edumazet(a)google.com> wrote:[...]The "peer" is this case is our user-space protocol splicer, emulating the behavior of of the remote end socket. At a first glance, it looks like it is *not* performing any retransmits at all when it sees a zero window at the receiver, so this might indeed be the problem. I will be out of office today, but I will test this later this week. ///jon>> [5201<->54494]: tcp_recvmsg_locked(<-) returning -11 bytes, window now: 250164, qlen: 0 >> >> We can see that although we are adverising a window size of zero, >> tp->rcv_wnd is not updated accordingly. This leads to a discrepancy >> between this side's and the peer's view of the current window size. >> - The peer thinks the window is zero, and stops sending.Hi! In my original logic, the client will send a zero-window ack when it drops the skb because it is out of the memory. And the peer SHOULD keep retrans the dropped packet. Does the peer do the transmission in this case? The receive window of the peer SHOULD recover once the retransmission is successful.>> - This side ends up in a cycle where it repeatedly caclulates a new >> window size it finds too small to advertise.Yeah, the zero-window suppressed the sending of ack in __tcp_cleanup_rbuf, which I wasn't aware of. The ack will recover the receive window of the peer. Does it make the peer retrans the dropped data immediately? In my opinion, the peer still needs to retrans the dropped packet until the retransmission timer timeout. Isn't it? If it is, maybe we can do the retransmission immediately if we are in zero-window from a window-shrink, which can make the recovery faster. [......]Thanks for CC the new email of mine, it's very kind of you, xing :/Any particular reason to not cc Menglong Dong ? (I just did)He is not working at Tencent any more. Let me CC here one more time.