From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=dDdklzho; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 3431E5A026F for ; Mon, 03 Nov 2025 04:11:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1762139485; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3Udih5NmMEwmojW+Sw2qGOVUVY6TH2zOWTlMyT/TvIQ=; b=dDdklzhop9wliHYzVvTera/DNFHGBcu7LhTmQo2zBFp/poUeRmevnNbxGcRMhHswk8k0AB XN1Wxvlfha01pAAWJ/biw6V6ejtDZHUJcmbmFY/5YFwFpmtNH2fE0tlTVKDSXPiHq/cUod p0DsWH12OQvpBbYKr8CaEwiFBaEeQt8= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-511-yZLO51LLNdOsNLW1of2hSg-1; Sun, 02 Nov 2025 22:11:23 -0500 X-MC-Unique: yZLO51LLNdOsNLW1of2hSg-1 X-Mimecast-MFC-AGG-ID: yZLO51LLNdOsNLW1of2hSg_1762139483 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-6407bd092b6so3267255a12.1 for ; Sun, 02 Nov 2025 19:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762139483; x=1762744283; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3Udih5NmMEwmojW+Sw2qGOVUVY6TH2zOWTlMyT/TvIQ=; b=hoGsetspTX73fJlTOFcMtFPnYpO+qXy3fj7m+kgJ0uQsyGuunBcmB1rtkrsth7qzcA 1m65BiDupiY7WGUUntQVDSDWUujGaHA2gFp6Hnb2OyuhYvpCl420pxwiH8unWQxZy+yG qGcuad936IICXYMO4AlhiMi4dF2V0CSTKbQkdzNeWn5Ix2ckq0ncGRsdREgY56bsryAS VgEVXl1iBx8Yiojrdt5RXHm8mc27mMNaSRGWz5Krj/YMj8LNIbP1+EaVMwWHQguGUXYg PB2slfTJkm0g8DHLhGX6HlFPxtvqZrz4wm5W4tTor/szZn3I5iUEvabRdGx8OL9zBvxL ljXg== X-Gm-Message-State: AOJu0YxJ0Amui+p5/PTc33cvIVnlP2/2Lw+9+0SOVgsmG+VQIQgAqFnK grW9RqfeCWYJvq3tV3NhCk3QvRbnV4Qo9svjkrjog+VO+kRGj6m7YKdpDaMJ9PBOgLwT9K5s9JB SodLB3pXk3D1q4xm/pN7iqrcQzDxQnvTZSlA9thHsNmvJV+yIi8XhidYgukyvpPOzaQyEJdTmi6 dEUzQpe5bDxMo7FqGZGSPdtuMumL3Y X-Gm-Gg: ASbGncusPGyNruj740ufvaqy34AqfkPuyl2eYZLn/cH2ac3hmohM9En8zIIT81Sop3V cbKkywKeJ3f3Kfpw1OnhDgUC2pFWd9gulxekTiYVeeYy4kHCpzi84xT+Tu+TqRS0PG80CM4BQPi 8H5Te4i+ucUzF1EIaN5tCuH5hLHHLtD3P6wiFvPMSlTuTSYUG0ONR25ulM X-Received: by 2002:a05:6402:35d6:b0:640:b736:6c2f with SMTP id 4fb4d7f45d1cf-640b7366e62mr2564346a12.18.1762139482649; Sun, 02 Nov 2025 19:11:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IG7wb40/9pjix/RChafe6Wn17sNoRjzbmqxyeRUO7ImNuD7yd0DPz6RvSUaA5GwIReSPx9Ve2TEwwqpU81F5yI= X-Received: by 2002:a05:6402:35d6:b0:640:b736:6c2f with SMTP id 4fb4d7f45d1cf-640b7366e62mr2564327a12.18.1762139481882; Sun, 02 Nov 2025 19:11:21 -0800 (PST) MIME-Version: 1.0 References: <20251031054242.7334-1-yuhuang@redhat.com> <20251031054242.7334-6-yuhuang@redhat.com> <20251031093822.6fa93b7e@elisabeth> In-Reply-To: <20251031093822.6fa93b7e@elisabeth> From: Yumei Huang Date: Mon, 3 Nov 2025 11:11:10 +0800 X-Gm-Features: AWmQ_bn9Ok7VZpzomy0D-26Dj3qymAVC1gLPah69MME4w0DG-J48v8LQXPS5pRk Message-ID: Subject: Re: [PATCH v7 5/5] tcp: Clamp the retry timeout To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: kppQ_dIg9omvl2oxMIPMHgyUgTbefbS5XhlgrgTR0s8_1762139483 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 322HN3KKJ4JN7EE3ZXIIXVIURTPYUFQN X-Message-ID-Hash: 322HN3KKJ4JN7EE3ZXIIXVIURTPYUFQN X-MailFrom: yuhuang@redhat.com 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, david@gibson.dropbear.id.au 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: On Fri, Oct 31, 2025 at 4:38=E2=80=AFPM Stefano Brivio = wrote: > > On Fri, 31 Oct 2025 13:42:42 +0800 > Yumei Huang wrote: > > > Clamp the TCP retry timeout as Linux kernel does. If RTO is less > > than 3 seconds, re-initialize it to 3 seconds for data retransmissions > > according to RFC 6298. > > > > Suggested-by: Stefano Brivio > > Signed-off-by: Yumei Huang > > --- > > tcp.c | 25 ++++++++++++++++++++----- > > tcp.h | 2 ++ > > 2 files changed, 22 insertions(+), 5 deletions(-) > > > > diff --git a/tcp.c b/tcp.c > > index 96ee56a..84a6700 100644 > > --- a/tcp.c > > +++ b/tcp.c > > @@ -187,6 +187,9 @@ > > * for established connections, or (tcp_syn_retries + > > * tcp_syn_linear_timeouts) times during the handshake, reset the co= nnection > > * > > + * - RTO_INIT_ACK: if the RTO is less than this, re-initialize RTO to = this for > > Nit: we started with BrE (British English) spelling and later tried to > keep that consistent for the sake of grep, so we'll usually use > "initialise" (for consistency, at this point). Got it. > > > + * data retransmissions. > > + * > > * - FIN_TIMEOUT: if a FIN segment was sent to tap/guest (flag ACK_FRO= M_TAP_DUE > > * with TAP_FIN_SENT event), and no ACK is received within this 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, RFC 6298 */ > > #define FIN_TIMEOUT 60 > > #define ACT_TIMEOUT 7200 > > > > @@ -365,9 +369,11 @@ uint8_t tcp_migrate_rcv_queue [TCP_MIGR= ATE_RCV_QUEUE_MAX]; > > > > #define TCP_SYN_RETRIES "/proc/sys/net/ipv4/tcp_syn_retri= es" > > #define TCP_SYN_LINEAR_TIMEOUTS "/proc/sys/net/ipv4/tcp_syn_linea= r_timeouts" > > +#define TCP_RTO_MAX_MS "/proc/sys/net/ipv4/tcp_r= to_max_ms" > > > > #define TCP_SYN_RETRIES_DEFAULT 6 > > #define TCP_SYN_LINEAR_TIMEOUTS_DEFAULT 4 > > +#define TCP_RTO_MAX_MS_DEFAULT 120000 > > > > /* "Extended" data (not stored in the flow table) for TCP flow migrati= on */ > > static struct tcp_tap_transfer_ext migrate_ext[FLOW_MAX]; > > @@ -585,10 +591,13 @@ static void tcp_timer_ctl(const struct ctx *c, st= ruct tcp_tap_conn *conn) > > if (conn->flags & ACK_TO_TAP_DUE) { > > it.it_value.tv_nsec =3D (long)ACK_INTERVAL * 1000 * 1000; > > } 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 > > + timeout =3D MAX(timeout, RTO_INIT_ACK); > > + timeout <<=3D MAX(exp, 0); > > + it.it_value.tv_sec =3D MIN(timeout, c->tcp.tcp_rto_max); > > } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) { > > it.it_value.tv_sec =3D FIN_TIMEOUT; > > } else { > > @@ -2785,18 +2794,24 @@ static socklen_t tcp_probe_tcp_info(void) > > */ > > void tcp_get_rto_params(struct ctx *c) > > { > > - intmax_t tcp_syn_retries, syn_linear_timeouts; > > + intmax_t tcp_syn_retries, syn_linear_timeouts, tcp_rto_max_ms; > > > > tcp_syn_retries =3D read_file_integer( > > TCP_SYN_RETRIES, TCP_SYN_RETRIES_DEFAULT); > > syn_linear_timeouts =3D read_file_integer( > > TCP_SYN_LINEAR_TIMEOUTS, TCP_SYN_LINEAR_TIMEOUTS_DEFAULT)= ; > > + tcp_rto_max_ms =3D read_file_integer( > > + TCP_RTO_MAX_MS, TCP_RTO_MAX_MS_DEFAULT); > > > > c->tcp.tcp_syn_retries =3D MIN(tcp_syn_retries, UINT8_MAX); > > c->tcp.syn_linear_timeouts =3D MIN(syn_linear_timeouts, UINT8_MAX= ); > > + c->tcp.tcp_rto_max =3D MIN( > > + DIV_ROUND_CLOSEST(tcp_rto_max_ms, 1000), SIZE_MAX); > > size_t looks like a rather weird choice for tcp_rto_max: size_t is used > to represent the size of objects, and nothing else (not a timeout in > milliseconds). > > It's also an int in ipv4_net_table[], net/ipv4/sysctl_net_ipv4.c > (Linux kernel). Any reason for picking size_t here? No particular reason. Just thought it can be used for counting as well. I can change it to int in v8. > > I mean, it will work, it just looks weird (and wastes a tiny bit of space= , > even though I guess we don't care about 4 bytes there). > > > - debug("Read sysctl values tcp_syn_retries: %"PRIu8", linear_timeo= uts: %"PRIu8, > > - c->tcp.tcp_syn_retries, c->tcp.syn_linear_timeouts); > > + debug("Read sysctl values tcp_syn_retries: %"PRIu8 > > + ", linear_timeouts: %"PRIu8", tcp_rto_max: %zu", > > + c->tcp.tcp_syn_retries, c->tcp.syn_linear_timeouts, > > + c->tcp.tcp_rto_max); > > } > > > > /** > > diff --git a/tcp.h b/tcp.h > > index befedde..a238bb7 100644 > > --- a/tcp.h > > +++ b/tcp.h > > @@ -59,6 +59,7 @@ union tcp_listen_epoll_ref { > > * @fwd_out: Port forwarding configuration for outbound packet= s > > * @timer_run: Timestamp of most recent timer run > > * @pipe_size: Size of pipes for spliced connections > > + * @tcp_rto_max: Maximal retry timeout (in s) > > Nit: "maximal" has a slightly different meaning compared to "maximum". > > The highest value allowed for a field would typically be called > "maximum", while "maximal" is more commonly used to indicate a value / > element that's the biggest of all values. Yes, I know, it's complicated. Yeah, it's complicated. Actually I get the word from networking/ip-sysctl.r= st. tcp_rto_max_ms - INTEGER Maximal TCP retransmission timeout (in ms). "maximum" might be more appropriate as you explained. > > > * @tcp_syn_retries: SYN retries using exponential backoff timeout > > * @syn_linear_timeouts: SYN retries before using exponential backoff = timeout > > */ > > @@ -67,6 +68,7 @@ struct tcp_ctx { > > struct fwd_ports fwd_out; > > struct timespec timer_run; > > size_t pipe_size; > > + size_t tcp_rto_max; > > uint8_t tcp_syn_retries; > > uint8_t syn_linear_timeouts; > > }; > > The rest of the series looks good to me at a *very* quick glance, but I > can't claim I really reviewed it yet. Thank you. Please take your time if you'd like to review them further. > > -- > Stefano > --=20 Thanks, Yumei Huang