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=202510 header.b=yaJKnTYT; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 9C0E45A0619 for ; Fri, 05 Dec 2025 03:53:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1764903199; bh=Vlns3m+IBWae/dSagatUr/Cz9NqGXaNCVTZIl3dpMio=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=yaJKnTYTpWNimmJ0eyfFSOzhEeDRGmDrDwE4ANYNf+rnPn/Rkgo8o9/1tKQRJ2YOn LqMS6fWGSSe07LeaiDVkrayf2/Kz3SPeDCh2tSWnwJ6IvmcXeQU/2LiuymGT6b632l z4CctqwT9VMp74IXlNJ/kXsstdaKxJTODU8o2Fdqt2+kqgUOmgRA96/9XJcetWIGoL mE5C2ZxOtLo4uXW6yi/uSdG6Sfn21vU3SoqJrTHaHubC95v9YZgnZiMqqIV5gXLwuq kc13JMztWo1ZE6rJ4fi8XGuG5Twc0NUjRyzj8xV9DAN20MwG3LfWHGN7hTMoFaXztV yuCHggij+SvFg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dMwt74gCnz4wGv; Fri, 05 Dec 2025 13:53:19 +1100 (AEDT) Date: Fri, 5 Dec 2025 13:53:06 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 5/8] tcp: Don't limit window to less-than-MSS values, use zero instead Message-ID: References: <20251204074542.2156548-1-sbrivio@redhat.com> <20251204074542.2156548-6-sbrivio@redhat.com> <20251205022016.4554e520@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2yoIreED5M+zlPoS" Content-Disposition: inline In-Reply-To: <20251205022016.4554e520@elisabeth> Message-ID-Hash: G37WN46RL6OGIKA2UHWZYHSHPAGV6VX3 X-Message-ID-Hash: G37WN46RL6OGIKA2UHWZYHSHPAGV6VX3 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, Max Chernoff 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: --2yoIreED5M+zlPoS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 05, 2025 at 02:20:16AM +0100, Stefano Brivio wrote: > On Fri, 5 Dec 2025 11:35:22 +1100 > David Gibson wrote: >=20 > > On Thu, Dec 04, 2025 at 08:45:38AM +0100, Stefano Brivio wrote: > > > If the sender uses data clumping (including Nagle's algorithm) for > > > Silly Window Syndrome (SWS) avoidance, advertising less than a MSS > > > means the sender might stop sending altogether, and window updates > > > after a low window condition are just as important as they are in > > > a zero-window condition. > > >=20 > > > For simplicity, approximate that limit to zero, as we have an > > > implementation forcing window updates after zero-sized windows. > > >=20 > > > Signed-off-by: Stefano Brivio =20 > >=20 > > The logic change looks good to me, so, > >=20 > > Reviewed-by: David Gibson > >=20 > > However, a couple of points about the description (both commit message > > and comment). > >=20 > > * Nagle's algorithm is certainly related, but it's not clear to me > > it's quite the same thing as the sender-side SWS avoidance > > algorithm - Nagle's exists for a different purpose, certainly. > > RFC 813 doesn't name Nagle's algorithm anywhere, although that > > could because the name wasn't as established at the time. >=20 > Sure, Nagle's algorithm was published almost two years later (RFC 896). >=20 > > * Since you're referencing RFC 813 anyway, it seems relevant that > > what you're doing here is pretty similar to the receiver-side SWS > > avoidance algorithm described in section 4. >=20 > The practical problem I observed comes from the "clumping" Linux does > while sending (and that's implemented as part of Nagle's algorithm). Ok. I guess you could look at Nagle's algorithm as (amongst other things) a refinement of the sender-side anti-SWS angorithm in RFC 813. > But yes I actually ignored section 4 in all this, I'll mention it > explicitly. >=20 > > > --- > > > tcp.c | 12 ++++++++++++ > > > 1 file changed, 12 insertions(+) > > >=20 > > > diff --git a/tcp.c b/tcp.c > > > index fbf97a0..2220059 100644 > > > --- a/tcp.c > > > +++ b/tcp.c > > > @@ -1140,6 +1140,18 @@ int tcp_update_seqack_wnd(const struct ctx *c,= struct tcp_tap_conn *conn, > > > else > > > limit =3D SNDBUF_GET(conn) - (int)sendq; > > > =20 > > > + /* If the sender uses Nagle's algorithm to prevent Silly Window > > > + * Syndrome (SWS, RFC 813 Section 3) it's critical that, should > > > + * the window ever become less than the MSS, we advertise a new > > > + * value once it increases again to be above it. > > > + * > > > + * To this end, for simplicity, approximate a window value below > > > + * the MSS to zero, as we already have mechanisms in place to > > > + * force updates after the window becomes zero. > > > + */ > > > + if (limit < MSS_GET(conn)) > > > + limit =3D 0; > > > + > > > new_wnd_to_tap =3D MIN((int)tinfo->tcpi_snd_wnd, limit); > > > } > > > =20 > > > --=20 > > > 2.43.0 >=20 > --=20 > Stefano >=20 --=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 --2yoIreED5M+zlPoS Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkySREACgkQzQJF27ox 2Ge/rRAAkr4SbjT9qC9WFFS6a5ALt+axU4w0BafEfLnfs80AV8fioagC5N1RFHNQ +sJJs76kOQ6MOyNXwGyfChM8vRHRXceMB6/UF/iGJ6reg69fWVufrCtJYV0Qhe3c 0R739dtS+atsp1ncC1F6UIbs9U+feJaojRBTPCwiCSvTvWqGqXcArC90K9p/hK9y KxgVSqsHMzHFtK+Fye9od7vQ9d0tfmQ7YdCQ6FSSZL1t3ZOEE0IiXGG6bqimlt8n YU4O3XmynF1qa1I+Ld47sVnja97rLr+rF56sLgft3ryMPXCFwrnrgIg1s3PWbW/q JecB16fa6LlyxuCgpty7RsR5KG5CX7V7wJ1piwdNPSRsjb8eSACA1niaMKvFBFjV bkealAHgnJWnkD8Gc5tGoyZnepahNgLlpLQytsbldRq4FZ2nsNOPCmhgEU0kyRRh l7iExSUa757megmz01ISj5FZYebwz4zlHRyj4lqTD65bN06HRqvunjy1SVT5MGwU MIlqKRHRrB9eO0QjOnS82CG0oND9Wx8pS5jeV+PZoj4PtAJ7+KrkBb2XqthPsB/c voMCqzsKPOXW86X0V0odrPt/YT7hnkpBjEqqWqZKdm2h8GRXN3jE4V8+hgNEeM8w VWaiH8jYPpGjOCo+9Tt4jQ4N0dNAJcRrmsDH2OBCsDD4pE8nwhc= =FcRb -----END PGP SIGNATURE----- --2yoIreED5M+zlPoS--