Re: [net-next 2/2] tcp: correct handling of extreme menory squeeze

8 Apr 2024


      ...
On Sun, Apr 7, 2024 at 2:52 PM Jason Xing  wrote:
...
On Sun, Apr 7, 2024 at 2:38 AM Eric Dumazet  wrote:
[...]
...
...
[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.
The "peer" is this case is our user-space protocol splicer, emulating
On 2024-04-07 03:51, Menglong Dong wrote:
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
...
...
...
...
- 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.
[......]
...
...
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.
Thanks for CC the new email of mine, it's very kind of you,
xing :/

Re: [net-next 2/2] tcp: correct handling of extreme menory squeeze

Jon Maloy