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=P9qeLWiS; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 1CC6E5A0619 for ; Mon, 13 Oct 2025 02:30:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1760315403; bh=J/fbUHCFVrD7IA/NJSkRPNm+sn67gX4m8I7gB7f726I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P9qeLWiSupcyARegCw7c0m83F6eE99pCuEBiXfLF71DWIBfiWfWTDv9CrEA9P7s+D CERlGwryPZC5ihQZuOGoaMnGEiVJi/9Q+EQ/nEAS6mSLBHT7YjiJ6vS5RZM8twNH0m x0s4EzylRaBEVACWdQN9ywHjSzYaQ1s/MPqagt9CwkMr08U5RmW3Fp+chh89o4e00G GIHdnIHJT2HKio8iiCwbpvwttmPFYBLZxzOAVsjExygOe6GxfI2bfOC4ewIFd9SJcs gmMbKaGU7Spmv2iSifef3G4xgeKDZSySiNHPDyvixHC7egZuzku7af4TtLfpxgeFHW TXH0eZtJDBvuw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4clJCH0QPTz4w9s; Mon, 13 Oct 2025 11:30:03 +1100 (AEDT) Date: Mon, 13 Oct 2025 11:29:59 +1100 From: David Gibson To: Yumei Huang Subject: Re: [PATCH v2 3/3] tcp: Update data retransmission timeout Message-ID: References: <20251010074700.22177-1-yuhuang@redhat.com> <20251010074700.22177-4-yuhuang@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n4UEpUaU7JH3QAUz" Content-Disposition: inline In-Reply-To: <20251010074700.22177-4-yuhuang@redhat.com> Message-ID-Hash: X3TXUKIHNN4APNIPP4KC4QBMS2NCMK64 X-Message-ID-Hash: X3TXUKIHNN4APNIPP4KC4QBMS2NCMK64 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, sbrivio@redhat.com 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: --n4UEpUaU7JH3QAUz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 10, 2025 at 03:47:00PM +0800, Yumei Huang wrote: > Use an exponential backoff timeout with the initial timeout 1s > and total timeout 60s. The commit message needs more information on why making this change to behaviour is desirable (e.g. referencing RFCs). >=20 > Signed-off-by: Yumei Huang > --- > tcp.c | 25 +++++++++++++++++++------ > 1 file changed, 19 insertions(+), 6 deletions(-) >=20 > diff --git a/tcp.c b/tcp.c > index 85bbdac..0db7f30 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -185,10 +185,15 @@ > * for more than TCP_MAX_RETRIES or (tcp_syn_retries + > * tcp_syn_linear_timeouts) times in a row, reset the connection > * > - * - ACK_TIMEOUT: if no ACK segment was received from tap/guest, after s= ending > - * data (flag ACK_FROM_TAP_DUE with ESTABLISHED event), re-send data f= rom the > - * socket and reset sequence to what was acknowledged. If this persist= s for > - * more than TCP_MAX_RETRIES times in a row, reset the connection > + * - ACK_TIMEOUT_INIT: if no ACK segment was received from tap/guest, af= ter > + * sending data (flag ACK_FROM_TAP_DUE with ESTABLISHED event), re-sen= d data > + * from the socket and reset sequence to what was acknowledged. It's t= he > + * starting timeout for the first retransmission. If this persists for= more > + * than TCP_MAX_RETRIES times in a row, reset the connection > + * > + * - ACK_TIMEOUT_TOTAL: if no ACK segment was received from tap/guest af= ter > + * retransmitting data repeatedly from the socket within this time, re= set > + * the connection > * > * - FIN_TIMEOUT: if a FIN segment was sent to tap/guest (flag ACK_FROM_= TAP_DUE > * with TAP_FIN_SENT event), and no ACK is received within this time, = reset > @@ -344,7 +349,8 @@ enum { > =20 > #define ACK_INTERVAL 10 /* ms */ > #define SYN_TIMEOUT_INIT 1 /* s */ > -#define ACK_TIMEOUT 2 > +#define ACK_TIMEOUT_INIT 1 > +#define ACK_TIMEOUT_TOTAL 60 > #define FIN_TIMEOUT 60 > #define ACT_TIMEOUT 7200 > =20 > @@ -358,6 +364,9 @@ enum { > ((conn)->events & (SOCK_FIN_RCVD | TAP_FIN_RCVD))) > #define CONN_HAS(conn, set) (((conn)->events & (set)) =3D=3D (set)) > =20 > +#define RETRY_ELAPSED(timeout_init, retries) \ > + ((timeout_init) * ((1 << ((retries) + 1)) - 2)) > + > /* Buffers to migrate pending data from send and receive queues. No, the= y don't > * use memory if we don't use them. And we're going away after this, so = splurge. > */ > @@ -596,7 +605,7 @@ static void tcp_timer_ctl(const struct ctx *c, struct= tcp_tap_conn *conn) > (conn->retries - c->tcp.syn_linear_timeouts); > } > else > - it.it_value.tv_sec =3D ACK_TIMEOUT; > + it.it_value.tv_sec =3D ACK_TIMEOUT_INIT << conn->retries; > } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) { > it.it_value.tv_sec =3D FIN_TIMEOUT; > } else { > @@ -2438,6 +2447,10 @@ void tcp_timer_handler(const struct ctx *c, union = epoll_ref ref) > } else if (conn->retries =3D=3D TCP_MAX_RETRIES) { > flow_dbg(conn, "retransmissions count exceeded"); > tcp_rst(c, conn); > + } else if(RETRY_ELAPSED(ACK_TIMEOUT_INIT, conn->retries) >=3D > + ACK_TIMEOUT_TOTAL) { > + flow_dbg(conn, "retransmissions timeout exceeded"); > + tcp_rst(c, conn); Having a test both for number of retries and time elapsed seems redundant. RETRY_ELAPSED is pure function of the number of retries, so it should be possible to just have a threshold on the number of retries, which can be calculated from the target total timeout. > } else { > flow_dbg(conn, "ACK timeout, retry"); > =20 > --=20 > 2.47.0 >=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 --n4UEpUaU7JH3QAUz Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjsSAcACgkQzQJF27ox 2GfnQQ//bh4+YeIOAUk48GYCHwkto+GwXWNQaWfcyvis371Chk9tUM61mH5Wgb4/ wf1/mS4kso8ngbUAVnQSm46yeA2T/PdD/VHtUePx3j5SsGSzWFUGJye7fz9Rr3Nh BokEfGhmqLjie4EwqiDg4xUoeJKnvZm/AaUdw10x/X6lcZOgg1CWf8O9SU58ZjKy ldD4xnqIBYOk8YT/VuaP5W/A/dhy+GVgOuU2tLNQ3wkVu2Rn0nmknRc1dircI2r3 ZnJNVsiSLdu4V06OaseCyM3b1/JqKGkU0XzNsJcoemmwvfXaGW3tQ0mvDNZXFis5 0eAtRyqylT16PWQllP/mH/CTJyWDR+I3q5ncnHgf26bh5yT2KjyYI5B+sT26l9dk BDGi3/B7/vd9RNEli04bsZTwWEY3cbHWJnB7TLdxx+kXNKmuS0RlriHQBDp9c4Xc tB1C+f8F2T5xguFI0NaISBKB+nP56/p6ci4XVCxrbQqAfkzowna4fSbyNVb90Le9 2AQrkF0QzPSmBUGyqXCE5qa12S2jLcm9KldNOdw1fTCesyGMqScufDhpkcz3nJtf yYEwPVH6S7MNG8Y7O8mJi1a6t7vPDrwIPESmt+h37ayZMz8AhQ+aOe+fLMY30UIj HnmedwqfSy80SLp0pIgXNLwMpTuptulyruqJsCTC+sHehxjZcC4= =a75K -----END PGP SIGNATURE----- --n4UEpUaU7JH3QAUz--