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=Wf5mXnKe; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 376F35A0619 for ; Wed, 29 Oct 2025 01:35:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1761698137; bh=OBmAqZNsmLF6gUAtW5ee2Pjh1xoMDa1zHdZxlzT6tSk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Wf5mXnKeT02In9Pzg91xoH8wUG+6FFDCz7pVyoJT2HnMmAob1sbKKf+LvWvyade31 4VaXqENBzzDs0hwCLsmxwxRYqiWudetpmBBK64oeAAoUiYAYYgwdMpz6jTs0vZPX3c hwtsYNnlqRyddsGBgVeuIxD4hIQBULWPHxHZP/2NYiWRXvvxbzQAgxMkR9Sow1o4Tf jt15Lt0CoXAuukLpqI2fGnDfwzl3MfkgocUfx7WJjH8aDCVU1cAVs15Rntohl4tmTn 409PalexpebxQCQ4ZiKXnz4M+eia1IlxaBx41oxOAi6h1Rk3d0etrxLcl1dODYF6YC mnIW5HZZ74huA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4cx7ZK0l5cz4wCm; Wed, 29 Oct 2025 11:35:37 +1100 (AEDT) Date: Wed, 29 Oct 2025 11:35:29 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 4/4] tcp: Update data retransmission timeout Message-ID: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-5-yuhuang@redhat.com> <20251017202812.173e9352@elisabeth> <20251020071107.42fd40e9@elisabeth> <20251029001330.579cc85a@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8RXaiHmqm1FKuElY" Content-Disposition: inline In-Reply-To: <20251029001330.579cc85a@elisabeth> Message-ID-Hash: 5WBOVBYCCHUS4H3ZWWQHKDKFRFX32MHI X-Message-ID-Hash: 5WBOVBYCCHUS4H3ZWWQHKDKFRFX32MHI 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: Yumei Huang , passt-dev@passt.top 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: --8RXaiHmqm1FKuElY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 29, 2025 at 12:13:30AM +0100, Stefano Brivio wrote: > On Mon, 20 Oct 2025 20:17:10 +1100 > David Gibson wrote: >=20 > > On Mon, Oct 20, 2025 at 07:11:07AM +0200, Stefano Brivio wrote: > > > On Mon, 20 Oct 2025 11:20:19 +1100 > > > David Gibson wrote: [snip] > > > > > Rather than the local link I was thinking of whatever monitor or > > > > > liveness probe in KubeVirt which might have a 60-second period, o= r some > > > > > firewall agent, or how long it typically takes for guests to stop= and > > > > > resume again in KubeVirt. =20 > > > >=20 > > > > Right, I hadn't considered those. Although.. do those actually re-= use > > > > a single connection? I would have guessed they use a new connection > > > > each time, making the timeouts here irrelevant. =20 > > >=20 > > > It depends on the definition of "each time", because we don't time out > > > host-side connections immediately. =20 > >=20 > > Hm, ok. Is your concern that getting a negative answer from the probe > > will take too long? >=20 > More like getting a positive answer taking too long, because we retry > so infrequently. Right, but it will only be slow if we lose the first probe, which should be very rare. > > > Pretending passt isn't there, the timeout would come from the default > > > values for TCP connections. It looks like there's no specific > > > SO_SNDTIMEO value set for those probes, and you can't configure the > > > timeout, at least according to: > > >=20 > > > https://kubernetes.io/docs/tasks/configure-pod-container/configure-= liveness-readiness-startup-probes/#define-a-tcp-liveness-probe =20 > >=20 > > My guess would be that the probe would probably time out at the > > application level long before the TCP layer times out, but I don't > > know for sure. >=20 > I don't think so. What I was pointing out is that I couldn't find any > place in the implementation of those probes where a particular > *handshake timeout* (not probe interval) is set on top of Linux's > defaults, so timeouts at TCP layer and application level should be the > same (no additional timeout in application logic). Huh, that's mildly surprising to me. --=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 --8RXaiHmqm1FKuElY Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkBYVEACgkQzQJF27ox 2Gd1WQ/7Bug15c1OsWMn5uQGlInUpUXMSgvrstT9MM3ukQ2Ku3joGMLo25U/gtuZ k60d0gHl49v7SOKEzUMpCv4OazL6LbyGqH6j8EB/M4XrDbD0o31EtcAf1TVczA5/ 35WnZQNoIgLahzcnqkeguuniqygbHiWWcJx/x5QPQ8ITQTTi5nvk47whv+3fHkbI qtZuvMcaZ3P2TCcWFmEbrfiYbaqZsGZvJoHwgMA3t/hiYLZbYzkn0K4LGmNSahVP iMByFjqngxWV7fF6w0U8U0ZvorkegkcajCQ6BD2qoXj8vGcUqMNhgytykJOHSkk4 xspsCLxwGnrA/u6xvCx9zUK1q1KV6f0Fj4zBvTBjw8/PgjKtyBwNZUal8RTuC6sa VmHW6rSsSBC4VXbxwR/Byo08Z2hH2guH5UnSaU6ELcOYVqkPmr9mpx8Mu6SKuV6P C37nxoyEra6YIFsSIGJnygIP4UyIHt6DxzcWG8YSQoMAo4URZFENSReGdVbLsUUc JIin4qtjd1/9iiEsL2hZWz9FkT4rabsdjZ4r57kwyATaKVHUyiFaqATt2/bPbdyB B8Fomd5p0DeQauzQgUZopuITcHRR6AD1HOV6/lYG1jjmHEMp15FfLy9C0OFUCe/O 6o3cySAqv3Ebsu7Lmu6eQG7TwbONBadni5g61cWA3ZaL63JPOis= =NHXq -----END PGP SIGNATURE----- --8RXaiHmqm1FKuElY--