From: Stefano Brivio <sbrivio@redhat.com>
To: Yumei Huang <yuhuang@redhat.com>
Cc: passt-dev@passt.top, david@gibson.dropbear.id.au
Subject: Re: [PATCH v6 3/4] tcp: Resend SYN for inbound connections
Date: Fri, 24 Oct 2025 01:04:31 +0200 [thread overview]
Message-ID: <20251024010431.4329a843@elisabeth> (raw)
In-Reply-To: <20251017062838.21041-4-yuhuang@redhat.com>
On Fri, 17 Oct 2025 14:28:37 +0800
Yumei Huang <yuhuang@redhat.com> wrote:
> If a client connects while guest is not connected or ready yet,
> resend SYN instead of just resetting connection after 10 seconds.
>
> Use the same backoff calculation for the timeout as linux kernel.
Linux.
>
> Link: https://bugs.passt.top/show_bug.cgi?id=153
> Signed-off-by: Yumei Huang <yuhuang@redhat.com>
> ---
> tcp.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++--------
> tcp.h | 5 +++++
> 2 files changed, 52 insertions(+), 8 deletions(-)
>
> diff --git a/tcp.c b/tcp.c
> index 2ec4b0c..9385132 100644
> --- a/tcp.c
> +++ b/tcp.c
> @@ -179,9 +179,11 @@
> *
> * Timeouts are implemented by means of timerfd timers, set based on flags:
> *
> - * - SYN_TIMEOUT: if no ACK is received from tap/guest during handshake (flag
> - * ACK_FROM_TAP_DUE without ESTABLISHED event) within this time, reset the
> - * connection
> + * - SYN_TIMEOUT_INIT: if no ACK is received from tap/guest during handshake
> + * (flag ACK_FROM_TAP_DUE without ESTABLISHED event) within this time, resend
> + * SYN. It's the starting timeout for the first SYN retry. If this persists
"If this persists" makes sense for the existing ACK_TIMEOUT
description but not here, because it looks like it refers to "starting
timeout".
Coupled with the next patch, it becomes increasingly difficult to
understand what "this" persisting thing is.
Maybe directly say "Retry for ..., then reset the connection"? It's
shorter and clearer.
> + * 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 sending
> * data (flag ACK_FROM_TAP_DUE with ESTABLISHED event), re-send data from the
> @@ -340,7 +342,7 @@ enum {
> #define WINDOW_DEFAULT 14600 /* RFC 6928 */
>
> #define ACK_INTERVAL 10 /* ms */
> -#define SYN_TIMEOUT 10 /* s */
> +#define SYN_TIMEOUT_INIT 1 /* s */
Maybe mention RFC 6928 as done above? That's where this value comes
from.
I just noticed you do that in 4/4, so it's slightly nicer if you do
that right away here for ease of future reference, but not really
needed.
> #define ACK_TIMEOUT 2
> #define FIN_TIMEOUT 60
> #define ACT_TIMEOUT 7200
> @@ -365,6 +367,9 @@ uint8_t tcp_migrate_rcv_queue [TCP_MIGRATE_RCV_QUEUE_MAX];
>
> #define TCP_MIGRATE_RESTORE_CHUNK_MIN 1024 /* Try smaller when above this */
>
> +#define TCP_SYN_RETRIES "/proc/sys/net/ipv4/tcp_syn_retries"
> +#define TCP_SYN_LINEAR_TIMEOUTS "/proc/sys/net/ipv4/tcp_syn_linear_timeouts" \
This uses 121 columns. I'm not sure where all those tabs and \ come
from.
> +
> /* "Extended" data (not stored in the flow table) for TCP flow migration */
> static struct tcp_tap_transfer_ext migrate_ext[FLOW_MAX];
>
> @@ -581,8 +586,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 = (long)ACK_INTERVAL * 1000 * 1000;
> } else if (conn->flags & ACK_FROM_TAP_DUE) {
> - if (!(conn->events & ESTABLISHED))
> - it.it_value.tv_sec = SYN_TIMEOUT;
> + if (!(conn->events & ESTABLISHED)) {
> + if (conn->retries < c->tcp.syn_linear_timeouts)
> + it.it_value.tv_sec = SYN_TIMEOUT_INIT;
> + else
> + it.it_value.tv_sec = SYN_TIMEOUT_INIT <<
> + (conn->retries - c->tcp.syn_linear_timeouts);
Probably more readable, but I haven't tried: always start from
SYN_TIMEOUT_INIT, then multiply/shift if
conn->retries >= c->tcp.syn_linear_timeouts.
> + }
> else
> it.it_value.tv_sec = ACK_TIMEOUT;
> } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) {
> @@ -2409,8 +2419,17 @@ void tcp_timer_handler(const struct ctx *c, union epoll_ref ref)
> tcp_timer_ctl(c, conn);
> } else if (conn->flags & ACK_FROM_TAP_DUE) {
> if (!(conn->events & ESTABLISHED)) {
> - flow_dbg(conn, "handshake timeout");
> - tcp_rst(c, conn);
> + if (conn->retries >= TCP_MAX_RETRIES ||
> + conn->retries >= (c->tcp.tcp_syn_retries +
> + c->tcp.syn_linear_timeouts)) {
> + flow_dbg(conn, "handshake timeout");
> + tcp_rst(c, conn);
> + } else {
> + flow_trace(conn, "SYN timeout, retry");
> + tcp_send_flag(c, conn, SYN);
> + conn->retries++;
I think I already raised this point on a previous revision: this needs
to be zeroed as the connection is established, but I don't see that in
the current version.
> + tcp_timer_ctl(c, conn);
> + }
> } else if (CONN_HAS(conn, SOCK_FIN_SENT | TAP_FIN_ACKED)) {
> flow_dbg(conn, "FIN timeout");
> tcp_rst(c, conn);
> @@ -2766,6 +2785,24 @@ static socklen_t tcp_probe_tcp_info(void)
> return sl;
> }
>
> +/**
> + * tcp_syn_params_init() - Get initial SYN parameters for inbound connection
They're not initial, they'll be used for all the connections if I
understand correctly.
Maybe "Get SYN retries sysctl values"? I think the _init() in the
function name is also somewhat misleading.
> + * @c: Execution context
> +*/
> +void tcp_syn_params_init(struct ctx *c)
> +{
> + intmax_t tcp_syn_retries, syn_linear_timeouts;
> +
> + tcp_syn_retries = read_file_integer(TCP_SYN_RETRIES, 8);
Why 8? Perhaps a #define would help?
> + syn_linear_timeouts = read_file_integer(TCP_SYN_LINEAR_TIMEOUTS, 1);
> +
> + c->tcp.tcp_syn_retries = MIN(tcp_syn_retries, UINT8_MAX);
> + c->tcp.syn_linear_timeouts = MIN(syn_linear_timeouts, UINT8_MAX);
> +
> + debug("TCP SYN parameters: retries=%"PRIu8", linear_timeouts=%"PRIu8,
Similar to the comment above: these are not parameters of SYN segments
(which would seem to imply TCP options, such as the MSS).
We typically don't print C assignments, rather human-readable messages,
so that could be "Read sysctl values tcp_syn_retries: ...,
syn_linear_timeouts: ...".
> + c->tcp.tcp_syn_retries, c->tcp.syn_linear_timeouts);
> +}
> +
> /**
> * tcp_init() - Get initial sequence, hash secret, initialise per-socket data
> * @c: Execution context
> @@ -2776,6 +2813,8 @@ int tcp_init(struct ctx *c)
> {
> ASSERT(!c->no_tcp);
>
> + tcp_syn_params_init(c);
> +
> tcp_sock_iov_init(c);
>
> memset(init_sock_pool4, 0xff, sizeof(init_sock_pool4));
> diff --git a/tcp.h b/tcp.h
> index 234a803..4369b52 100644
> --- a/tcp.h
> +++ b/tcp.h
> @@ -59,12 +59,17 @@ union tcp_listen_epoll_ref {
> * @fwd_out: Port forwarding configuration for outbound packets
> * @timer_run: Timestamp of most recent timer run
> * @pipe_size: Size of pipes for spliced connections
> + * @tcp_syn_retries: Number of SYN retries during handshake
> + * @syn_linear_timeouts: Number of SYN retries using linear backoff timeout
> + * before switching to exponential backoff timeout
Maybe more compact:
* @syn_linear_timeouts: SYN retries before using exponential timeout
> */
> struct tcp_ctx {
> struct fwd_ports fwd_in;
> struct fwd_ports fwd_out;
> struct timespec timer_run;
> size_t pipe_size;
> + uint8_t tcp_syn_retries;
> + uint8_t syn_linear_timeouts;
> };
>
> #endif /* TCP_H */
--
Stefano
next prev parent reply other threads:[~2025-10-23 23:04 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 6:28 [PATCH v6 0/4] Retry SYNs " Yumei Huang
2025-10-17 6:28 ` [PATCH v6 1/4] tcp: Rename "retrans" to "retries" Yumei Huang
2025-10-17 6:28 ` [PATCH v6 2/4] util: Introduce read_file() and read_file_integer() function Yumei Huang
2025-10-19 10:07 ` Stefano Brivio
2025-10-21 9:32 ` Yumei Huang
2025-10-21 21:50 ` Stefano Brivio
2025-10-22 0:51 ` David Gibson
2025-10-22 8:42 ` Yumei Huang
2025-10-22 0:55 ` Yumei Huang
2025-10-23 23:04 ` Stefano Brivio
2025-10-24 3:16 ` David Gibson
2025-10-24 6:05 ` Yumei Huang
2025-10-28 7:11 ` Yumei Huang
2025-10-28 11:43 ` Stefano Brivio
2025-10-17 6:28 ` [PATCH v6 3/4] tcp: Resend SYN for inbound connections Yumei Huang
2025-10-22 1:16 ` David Gibson
2025-10-22 1:30 ` Yumei Huang
2025-10-22 2:26 ` David Gibson
2025-10-23 23:04 ` Stefano Brivio [this message]
2025-10-24 3:30 ` David Gibson
2025-10-24 8:37 ` Stefano Brivio
2025-10-24 10:55 ` David Gibson
2025-10-27 3:37 ` Yumei Huang
2025-10-27 6:49 ` Stefano Brivio
2025-10-28 7:43 ` Yumei Huang
2025-10-28 11:44 ` Stefano Brivio
2025-10-29 2:31 ` Yumei Huang
2025-10-17 6:28 ` [PATCH v6 4/4] tcp: Update data retransmission timeout Yumei Huang
2025-10-22 1:19 ` David Gibson
2025-10-22 8:40 ` Yumei Huang
2025-10-23 23:04 ` Stefano Brivio
2025-10-28 8:09 ` Yumei Huang
2025-10-28 11:44 ` Stefano Brivio
2025-10-28 11:54 ` Stefano Brivio
2025-10-29 3:06 ` Yumei Huang
2025-10-29 4:38 ` Stefano Brivio
2025-10-29 5:11 ` Yumei Huang
2025-10-29 7:09 ` Stefano Brivio
2025-10-29 7:32 ` Yumei Huang
2025-10-29 7:39 ` Stefano Brivio
2025-10-29 8:59 ` Yumei Huang
2025-10-29 12:18 ` Stefano Brivio
2025-10-30 8:25 ` Yumei Huang
2025-10-30 8:51 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251024010431.4329a843@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
--cc=yuhuang@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).