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=TQ32GAMq; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id AE1155A061E for ; Fri, 14 Nov 2025 05:18:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1763093923; bh=lr1z2eSLnlSw2zK0X6romgRAZ6Iqpg+J7mujbvjk2Mc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TQ32GAMqKGY2nN5I8qqM/WRd6qWu5KxjRYGE4/MSsKvDlevF4L9Gb45JUQ/hZbsO8 KBXzNeImpiJZrQVwJrIEEJmRkjPK0qSUHUx0svuByEsCttM2m1bm5e3iSOAW8qn7cl vuc0ZzOjBnB48MoL2iAGiZeg8WGeHwhZxN/IPA0ZDLkPSOLyhL1OyyrzvVl6KrUaUU 1IBUt53U9me2TU1XOuiDxgvo9G9uk9IPtquI/n99WHVixPT6x47TM2zq3oHQPmzCPQ RSMyU4R3in/2ydPTaVEu7FnqH9xlGemOMzSmm9t4oVprZNgEDAx9MkBqzZEgxoMw9D EtKfffC3Hte+Q== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4d73mM3vZXz4wyc; Fri, 14 Nov 2025 15:18:43 +1100 (AEDT) Date: Fri, 14 Nov 2025 14:35:12 +1100 From: David Gibson To: Yumei Huang Subject: Re: [PATCH v8 6/6] tcp: Clamp the retry timeout Message-ID: References: <20251110093137.87705-7-yuhuang@redhat.com> <20251114010121.10dfb18a@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ILFAuANeAs4E2eRA" Content-Disposition: inline In-Reply-To: Message-ID-Hash: U3Q2NR67INDM5P2J3ZCUVO74FWXHACQX X-Message-ID-Hash: U3Q2NR67INDM5P2J3ZCUVO74FWXHACQX 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: Stefano Brivio , 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: --ILFAuANeAs4E2eRA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2025 at 11:05:51AM +0800, Yumei Huang wrote: > On Fri, Nov 14, 2025 at 8:47=E2=80=AFAM David Gibson > wrote: > > > > On Fri, Nov 14, 2025 at 01:01:21AM +0100, Stefano Brivio wrote: > > > On Mon, 10 Nov 2025 21:56:39 +1100 > > > David Gibson wrote: > > > > > > > On Mon, Nov 10, 2025 at 05:31:37PM +0800, Yumei Huang wrote: > > > > > Clamp the TCP retry timeout as Linux kernel does. If a retry occu= rs > > > > > during the handshake and the RTO is below 3 seconds, re-initialise > > > > > it to 3 seconds for data retransmissions according to RFC 6298. > > > > > > > > > > Suggested-by: Stefano Brivio > > > > > Signed-off-by: Yumei Huang > > > > > > > > Looks correct, so > > > > > > > > Reviewed-by: David Gibson > > > > > > > > A few possible improvements (mostly comments/names) below. > > > > > > > > > --- > > > > > tcp.c | 25 ++++++++++++++++++++----- > > > > > tcp.h | 2 ++ > > > > > tcp_conn.h | 1 + > > > > > 3 files changed, 23 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/tcp.c b/tcp.c > > > > > index ee111e0..b015658 100644 > > > > > --- a/tcp.c > > > > > +++ b/tcp.c > > > > > @@ -187,6 +187,9 @@ > > > > > * for established connections, or (syn_retries + syn_linear_t= imeouts) times > > > > > * during the handshake, reset the connection > > > > > * > > > > > + * - RTO_INIT_ACK: if the RTO is less than this, re-initialise R= TO to this for > > > > > + * data retransmissions > > > > > + * > > > > > > > > Now that this is conditional on SYN being retried, the description > > > > doesn't look entirely accurate any more. > > > > > > If I read the whole thing again I would actually say it becomes > > > misleading and worth fixing before applying this. Also because the > > > relationship to the text in the RFC is not obvious anymore. > > > > > > This should be "if SYN retries happened during handshake, ...". > > > > > > > > * - FIN_TIMEOUT: if a FIN segment was sent to tap/guest (flag A= CK_FROM_TAP_DUE > > > > > * with TAP_FIN_SENT event), and no ACK is received within thi= s time, reset > > > > > * the connection > > > > > @@ -340,6 +343,7 @@ enum { > > > > > > > > > > #define ACK_INTERVAL 10 /* ms */ > > > > > #define RTO_INIT 1 /* s, RFC 6298 = */ > > > > > +#define RTO_INIT_ACK 3 /* s, R= FC 6298 */ > > > > > > > > The relevance of "_ACK" in the name is not obvious to me. > > > > > > What about RTO_INIT_AFTER_SYN_RETRIES? We use it only once, and it > > > looks fine there. > > > > Works for me. > > > > > > > #define FIN_TIMEOUT 60 > > > > > #define ACT_TIMEOUT 7200 > > > > > > > > > -> @@ -365,9 +369,11 @@ uint8_t tcp_migrate_rcv_queue = [TCP_MIGRATE_RCV_QUEUE_MAX]; > > > > > > > > > > #define SYN_RETRIES "/proc/sys/net/ipv4/tcp_syn_ret= ries" > > > > > #define SYN_LINEAR_TIMEOUTS "/proc/sys/net/ipv4/tcp_syn_lin= ear_timeouts" > > > > > +#define RTO_MAX_MS "/proc/sys/net/ipv4/tcp_rto_max= _ms" > > > > > > > > > > #define SYN_RETRIES_DEFAULT 6 > > > > > #define SYN_LINEAR_TIMEOUTS_DEFAULT 4 > > > > > +#define RTO_MAX_MS_DEFAULT 120000 > > > > > #define MAX_SYNCNT 127 /* derived from ker= nel's limit */ > > > > > > > > > > /* "Extended" data (not stored in the flow table) for TCP flow m= igration */ > > > > > @@ -392,7 +398,7 @@ static const char *tcp_state_str[] __attribut= e((__unused__)) =3D { > > > > > > > > > > static const char *tcp_flag_str[] __attribute((__unused__)) =3D { > > > > > "STALLED", "LOCAL", "ACTIVE_CLOSE", "ACK_TO_TAP_DUE", > > > > > - "ACK_FROM_TAP_DUE", "ACK_FROM_TAP_BLOCKS", > > > > > + "ACK_FROM_TAP_DUE", "ACK_FROM_TAP_BLOCKS", "SYN_RETRIED", > > > > > }; > > > > > > > > > > /* Listening sockets, used for automatic port forwarding in past= a mode only */ > > > > > @@ -590,10 +596,13 @@ static void tcp_timer_ctl(const struct ctx = *c, struct tcp_tap_conn *conn) > > > > > if (conn->flags & ACK_TO_TAP_DUE) { > > > > > it.it_value.tv_nsec =3D (long)ACK_INTERVAL * 1000 * 100= 0; > > > > > } else if (conn->flags & ACK_FROM_TAP_DUE) { > > > > > - int exp =3D conn->retries; > > > > > + int exp =3D conn->retries, timeout =3D RTO_INIT; > > > > > if (!(conn->events & ESTABLISHED)) > > > > > exp -=3D c->tcp.syn_linear_timeouts; > > > > > - it.it_value.tv_sec =3D RTO_INIT << MAX(exp, 0); > > > > > + else if (conn->flags & SYN_RETRIED) > > > > > + timeout =3D MAX(timeout, RTO_INIT_ACK); > > > > > + timeout <<=3D MAX(exp, 0); > > > > > + it.it_value.tv_sec =3D MIN(timeout, c->tcp.rto_max); > > > > > } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) { > > > > > it.it_value.tv_sec =3D FIN_TIMEOUT; > > > > > } else { > > > > > @@ -2440,6 +2449,7 @@ void tcp_timer_handler(const struct ctx *c,= union epoll_ref ref) > > > > > flow_trace(conn, "SYN timeout, retry"); > > > > > tcp_send_flag(c, conn, SYN); > > > > > conn->retries++; > > > > > + conn_flag(c, conn, SYN_RETRIED); > > > > > tcp_timer_ctl(c, conn); > > > > > } > > > > > } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED= )) { > > > > > @@ -2811,10 +2821,15 @@ void tcp_get_rto_params(struct ctx *c) > > > > > v =3D read_file_integer(SYN_LINEAR_TIMEOUTS, SYN_LINEAR_TIMEOUT= S_DEFAULT); > > > > > c->tcp.syn_linear_timeouts =3D MIN(v, MAX_SYNCNT); > > > > > > > > > > + v =3D read_file_integer(RTO_MAX_MS, RTO_MAX_MS_DEFAULT); > > > > > + c->tcp.rto_max =3D MIN(DIV_ROUND_CLOSEST(v, 1000), INT_MAX); > > > > > > > > Possibly we should verify this is =3D> RTO_INIT. > > > > > > As a sanity check, maybe, but I don't see any harmful effect if it's > > > < RTO_INIT, right? So I'm not sure if we should. No preference from my > > > side really. > > > > Sorry, describing this as >=3D RTO_INIT was misleading. What I'm > > concerned about here is if the kernel value is set to 400ms, we'll > > round it to... 0s. > > > > So, really what I'm concerned about is that we ensure this is > 0. >=20 > That's a good point. Actually, thinking about it, I wonder if makes more sense to always round up to 1s, rather than to the nearest 1s. > > > > > + > > > > > debug("Read sysctl values syn_retries: %"PRIu8 > > > > > - ", syn_linear_timeouts: %"PRIu8, > > > > > + ", syn_linear_timeouts: %"PRIu8 > > > > > + ", rto_max: %d", > > > > > c->tcp.syn_retries, > > > > > - c->tcp.syn_linear_timeouts); > > > > > + c->tcp.syn_linear_timeouts, > > > > > + c->tcp.rto_max); > > > > > } > > > > > > > > > > /** > > > > > diff --git a/tcp.h b/tcp.h > > > > > index 37d7758..c4945c3 100644 > > > > > --- a/tcp.h > > > > > +++ b/tcp.h > > > > > @@ -60,6 +60,7 @@ union tcp_listen_epoll_ref { > > > > > * @fwd_out: Port forwarding configuration for outbo= und packets > > > > > * @timer_run: Timestamp of most recent timer run > > > > > * @pipe_size: Size of pipes for spliced connections > > > > > + * @rto_max: Maximal retry timeout (in s) > > > > > > As pointed out earlier, I think "maximum" is slightly more appropriate > > > here. > > > > Agreed, with nuance discussed earlier. >=20 > Well, I must have misunderstood something in last week's meeting. I > joined the second half meeting a few mins later and I caught Stefano > saying he was wrong about maximal. Probably he was talking about the > French meaning. Anyway, I will update. Sorry, yeah, the discussion there was probably fairly confusing - I think both Stefano and I got a bit distracted from the question at hand by language-nerding. The upshot is that while I think both "maximal" and "maximum" would be correct, I think "maximum" is slightly clearer. > > > > > > > > > > * @syn_retries: SYN retries using exponential backoff timeout > > > > > * @syn_linear_timeouts: SYN retries before using exponential ba= ckoff timeout > > > > > */ > > > > > @@ -68,6 +69,7 @@ struct tcp_ctx { > > > > > struct fwd_ports fwd_out; > > > > > struct timespec timer_run; > > > > > size_t pipe_size; > > > > > + int rto_max; > > > > > uint8_t syn_retries; > > > > > uint8_t syn_linear_timeouts; > > > > > }; > > > > > diff --git a/tcp_conn.h b/tcp_conn.h > > > > > index 923af36..e36910c 100644 > > > > > --- a/tcp_conn.h > > > > > +++ b/tcp_conn.h > > > > > @@ -77,6 +77,7 @@ struct tcp_tap_conn { > > > > > #define ACK_TO_TAP_DUE BIT(3) > > > > > #define ACK_FROM_TAP_DUE BIT(4) > > > > > #define ACK_FROM_TAP_BLOCKS BIT(5) > > > > > +#define SYN_RETRIED BIT(6) > > > > > > > > > > #define SNDBUF_BITS 24 > > > > > unsigned int sndbuf :SNDBUF_BITS; > > > > > -- > > > > > 2.51.0 > > > > > > -- > > > Stefano > > > > > > > -- > > David Gibson (he or they) | I'll have my music baroque, and my co= de > > david AT gibson.dropbear.id.au | minimalist, thank you, not the other = way > > | around. > > http://www.ozlabs.org/~dgibson >=20 >=20 >=20 > --=20 > Thanks, >=20 > Yumei Huang >=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 --ILFAuANeAs4E2eRA Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkWo28ACgkQzQJF27ox 2GdhXxAAjkaucvswPimeqmVxDkpFqw6EM5eZ8YK0GIwSl+TJSpayYAZ/UQO2YTnt OSz2B6HCmBAoI5oEINJb/kRfsBcpm75OF3KRhdvnogydlOTitAdjrJ2F0CC/+Q+6 cKjx2uvN/6ptgGNZSCgrtHDixn+XqyYgApHlDaf8aJT6oFjRNLQd2f6g1jKcHgKo aMEBuWlmYYhcJFRN2oO5n7wiS3tI40M7O1MbIPDYuUxqD5zYCo0bOOiIu3TYtieH zUOZ7q3Aea45ayFuMcnAKyykiLacU0K5ior3qYLoxwxhRrW4CmgZrpViV8PWzxkb h7laCBsNqyENw2MQaGmja7LfEdXPZ4i57JGj9SyuIWN8Wv1t9uTi8RE5QnwK0Au+ gHgRmkRXKFGHOOBiWJl0w4NYW6I0AyW2TC0NX8mn0C9NEygphM2Vn0MJOsOeBxVy NqvgAKi2j+rfalh9xXZ1PDaLytPCdq1nM6qRCKcSAWxU1ASmF5pob/4wOpJKJQmQ nd9hNLqoO15gx2Hfank0uSUECXCt6K6RX9PHURrafCEdTbvYrspwdr94snOKxo9l AigOJZcEE8/m/Bd1JW5sOYYOgPzBIDZYNwDssAcN8ZEOnFzlfbm0stI0j3nVNw+4 mqxq/gpJNblenL6DtdUbSB0VWkWpw7+HQ77jlZ2aChD4bYI7gH8= =awLW -----END PGP SIGNATURE----- --ILFAuANeAs4E2eRA--