From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202508 header.b=VYw2pgHg; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 494CC5A0279 for ; Tue, 19 Aug 2025 02:55:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202508; t=1755564939; bh=hag5OMw8Nga5QLBd4x5Jt15LJdBXsBPDa8uZyurXkNU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VYw2pgHgHBurdy+0KC9WjEHEAoXrojV0NhjvWZ0pJD4rKny6wzjBH/02SNeLF59IB LbdUcZNFwruKbgp/GrCToCkzEEjeSS9xtthbGmEH3MPYXFgIFn3g3T0alZHxFya+nH FOPgznfXSPXyz2etBAYB6Tb1rznut691EFidVS9gfVTBH0vj5A4a9HhoVjyz7udA5y ZAw/tWYEDl92zu+RFt+xO2iWTrAXV54VdjwlO8I0qXPC5kOC7u53dlqdQrghpGykX1 DeDblT0GuoAJ8aXfZdYR6OVphJfqpy/ra067WKBdwR3E/G79gdbmQ44NkzOAt3IT/M Y1VOx6DC7DcfA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4c5WNC6RP6z4wbd; Tue, 19 Aug 2025 10:55:39 +1000 (AEST) Date: Tue, 19 Aug 2025 10:55:33 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 5/6] tcp: Don't try to transmit right after the peer shrank the window to zero Message-ID: References: <20250815161042.3606244-1-sbrivio@redhat.com> <20250815161042.3606244-6-sbrivio@redhat.com> <20250818190629.280f0e0c@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/N/TECEioSyJecvt" Content-Disposition: inline In-Reply-To: <20250818190629.280f0e0c@elisabeth> Message-ID-Hash: L3JCF5II5DVONZ55LPGCENM3UIJNDHSE X-Message-ID-Hash: L3JCF5II5DVONZ55LPGCENM3UIJNDHSE X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Jon Maloy , Paul Holzinger X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --/N/TECEioSyJecvt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 18, 2025 at 07:06:29PM +0200, Stefano Brivio wrote: > On Mon, 18 Aug 2025 12:56:09 +1000 > David Gibson wrote: >=20 > > On Fri, Aug 15, 2025 at 06:10:41PM +0200, Stefano Brivio wrote: > > > If the peer shrinks the window to zero, we'll skip storing the new > > > window, as a convenient way to cause window probes (which exceed any > > > zero-sized window, strictly speaking) if we don't get window updates > > > in a while. =20 > >=20 > > Strictly speaking, not storing the new zero window feels slightly > > wrong to me - I wonder if it would be more correct to store the zero > > window, but still send window probes as a special case. >=20 > Yeah, it's wrong but it's not really obvious what value we should use > at that point. With a recent kernel version, there would be no problem > storing 0, waiting for a window update which will come soon after, and > reserve the special case I already added (1 as window size) for > zero-window probes, triggered via timer. >=20 > But without 8c670bdfa58e ("tcp: correct handling of extreme memory > squeeze"), and with e2142825c120 ("net: tcp: send zero-window ACK when > no memory"), the window update never comes, so we would need to wait > for the timer to expire before we send an explicit zero-window probe, > which takes a while (two seconds). Right. I guess what I had in mind was to store the zero window, but also set up a new timer to send a new window-probe in a more reasonable timeframe. > With this trick, instead, we keep the latest advertised value, which > is actually the latest correct value, and retry sending what we were > originally sending as soon as we have more data from the socket, which > would becomes available quite soon in all the practical cases where the > kernel shrinks the window to zero. Ah, right. So, IIUC a part of the issue is that at this point if we see a zero window we don't know if it's because *we* filled the window in the normal way - and so should wait for an update - or because the peer slammed the window shut - in which case we need to reprobe. I mean, I guess we could set a flag for that earlier, but that's fairly awkward. At least for the time being, I think the current approach of keeping the previous window is preferable. > Maybe we could store zero, and use WINDOW_DEFAULT (14600 bytes) on > socket activity. The RFC simply says we need to send zero-window > probes at some point, not that we should assume a broken receiver, > but unfortunately between e2142825c120 and 8c670bdfa58e it's like that. I think the existing behaviour of keeping the previous window is preferable. At least for the specific case of a transient memory error, that seems more likely to be right. Maybe? Unless we think we should slow down in the hopes of not exhausting the peer's memory again. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --/N/TECEioSyJecvt Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmijy4QACgkQzQJF27ox 2GfCyBAAisFk905uCYMrDEPj0jrMRk2qfQZqD6eZkBP80HB8G3x8xdTMk4TVVkXz Hfy6fEXcoqsL2ln12NRv9n+njSEhBX8VByDy/aJmj8CBuHsiG/3bBdjpRjnYzpx3 hDToxmYP4x65P+QhQ0l929ZY95v2rg5psh64JMiM3dIedip9dBqbU2N3INe6K8Hq 8OHKFxP0y6E2zeLTDZyLU/8bcM1rSCfSNphYUBpYoDIhCbOmbjKke6ne3XRXq6kq xYZm/6Xb5RgmbtCOMvInISoVr2t8mzlED0rCqFARM8yTgZ9jE2qgcQvtDA422lCe VyBJHZ6/gbaqYoUtO9+NmqswAVH5bijcGQ7YRUImmFegT3S5+wsxkHEYnu/NIK+Y +VlE9jDtOAXuMMSmua9rO5pvPyMLvAi1KVMM9SL225FzWOotoLnCp/XwSu1heHtJ v82n8M1YXBdrMluqT8riKtAjP3mUJ9YB52/XeKgfJ5K7zET3H09j2yIP8xCez7XG TujQSXyVO6M6TNz5YyxtuBriTOLPuyPkhM7RTSftCmF3Ounm4Kz0xJt03SNBMt0v 16ny1mHBY8CgWsBHTRcpKIceqBYuzmFNKIykYW5TRBk1lE8e4Vx03c7CLq3eFotz mpA7kcEKamouhKbMVeKhGcrjvwGU1mcPOti+NsRZ0Z9wPxTITTE= =ysKX -----END PGP SIGNATURE----- --/N/TECEioSyJecvt--