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=OBoTpCIJ; 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 B824D5A061E for ; Fri, 14 Nov 2025 04:06:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763089566; 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=te5LP6C9xSXwSX2IQhs/FpTnjoaxbS7te4zWJyULjKc=; b=OBoTpCIJBXUMCP5zTlMXf7mSZetfpYAIxGWNUIW8ndcaKGWA3E2kridAspRgFmyD3K3AHy Tfody4cYLa4MU251Nclr4yaCiXOP+G3c/7ZWKEsDB8oNcCA9Jo9jSdVpGsoBL9Hw5b53yQ NxXBsQIWczanS1CXxEGpTZviqU4nBuM= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-hApW7cysNgG4KZIkytR5xQ-1; Thu, 13 Nov 2025 22:06:04 -0500 X-MC-Unique: hApW7cysNgG4KZIkytR5xQ-1 X-Mimecast-MFC-AGG-ID: hApW7cysNgG4KZIkytR5xQ_1763089564 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-b73405a2e7bso131768566b.0 for ; Thu, 13 Nov 2025 19:06:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763089563; x=1763694363; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=te5LP6C9xSXwSX2IQhs/FpTnjoaxbS7te4zWJyULjKc=; b=TYlaybAMTDrnXy1U4RQswpOgiq1ipO5zBGgzktHoabxHqFX9/C1ymY2rUYIV9/L32C 5jrI4+nwu0ZFDoGxQxjSJSiw62m1iJKhlROIDcRJEdO//z+fxM4YKLPuchG3WubxUIcH 3xFauGnV/8jOeI/92s31pI/ngeuA/waAkbozRcimHnSK+wTQwusoeVL2EWraGYYEDPj6 o0BwnPfz2ZO0/AkPHM0QdccPUCmwUylzin0h3x62uKfdBUQGrQh/Vee+gHTcVrVC8j3M g9NgRI2Uwcd/wP/4FViJrj8QJ9UkSOjhhbN6n8ebXPSAwouxS34rffKsvQkZI5sivhyo IQZw== X-Forwarded-Encrypted: i=1; AJvYcCWuYDFDYPiaKpzCKKbl4GJjPXW3ZrmI94hR0okXGeYNhiqhovlC4f/bOyd13PWnL37Bcu9GZdq/MyU=@passt.top X-Gm-Message-State: AOJu0YxT6lrAnZtlL2pjUo9rqgoK4JsOYpsUzUKMDDcsrLC06JD/0Hoz VYSshaXGamYhtvAdrRHBpILlGTl5egJ8e8LtXE7PXJbYBEnMA0e206T5D7+gfcmgdGVrmjRHDio xK4y4JjayQFeXxnQC7pDpSi/Q1EqYCuXx+Z+fliJFN97TKrUISogHdutbLFYb3YhLCN9AfrTsSp Kaqy3EIApbfUq82i2C3J7R0B/Dzd2k X-Gm-Gg: ASbGncv2gv/7vRLo3eK5tAGgmpt8y4TKwBHf51OQiCD4yvP0nQif6cOm9mmPZ6Azsox GPjob+MxOb1FwNNxucvo0HVU6a6QKVPQhyXSVf4D2Vn+jZgl4gudjPNWUyEPi87ueHoiGnePtrl WDSnsKPLc2B0wKJUOd2UkMu2TEzT+w+c3f6S7qUbYXXw2DreayOtPioyEm X-Received: by 2002:a17:906:478c:b0:b72:1ced:f213 with SMTP id a640c23a62f3a-b73678f4e72mr151364266b.37.1763089563468; Thu, 13 Nov 2025 19:06:03 -0800 (PST) X-Google-Smtp-Source: AGHT+IHu1Y1CiY/AJkicow2R1v/ZgaxQKb6mx0hYlOdbIatmqja33RCYVELCrcysX5sd1GzK6Rdff+zJdyqqKzRXGmY= X-Received: by 2002:a17:906:478c:b0:b72:1ced:f213 with SMTP id a640c23a62f3a-b73678f4e72mr151361266b.37.1763089562979; Thu, 13 Nov 2025 19:06:02 -0800 (PST) MIME-Version: 1.0 References: <20251110093137.87705-7-yuhuang@redhat.com> <20251114010121.10dfb18a@elisabeth> In-Reply-To: From: Yumei Huang Date: Fri, 14 Nov 2025 11:05:51 +0800 X-Gm-Features: AWmQ_bmLcrHXvgkqVr1XqzMr-KsGrLVNYXgy5M6u4QVawtOrh4oanC1JvS27aY0 Message-ID: Subject: Re: [PATCH v8 6/6] tcp: Clamp the retry timeout To: David Gibson X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: MTEJA6aKy_ZwlybkGk0rIJkdjyapFOXCBkjxDHwn_WA_1763089564 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: Q42YT7BKTZHUCXPW4AX3K5WKPA6S5J4Y X-Message-ID-Hash: Q42YT7BKTZHUCXPW4AX3K5WKPA6S5J4Y 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: 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: 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 occurs > > > > 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_tim= eouts) times > > > > * during the handshake, reset the connection > > > > * > > > > + * - RTO_INIT_ACK: if the RTO is less than this, re-initialise RTO= 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 ACK= _FROM_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 */ > > > > > > 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_retri= es" > > > > #define SYN_LINEAR_TIMEOUTS "/proc/sys/net/ipv4/tcp_syn_linea= r_timeouts" > > > > +#define RTO_MAX_MS "/proc/sys/net/ipv4/tcp_rto_max_m= s" > > > > > > > > #define SYN_RETRIES_DEFAULT 6 > > > > #define SYN_LINEAR_TIMEOUTS_DEFAULT 4 > > > > +#define RTO_MAX_MS_DEFAULT 120000 > > > > #define MAX_SYNCNT 127 /* derived from kerne= l's limit */ > > > > > > > > /* "Extended" data (not stored in the flow table) for TCP flow mig= ration */ > > > > @@ -392,7 +398,7 @@ static const char *tcp_state_str[] __attribute(= (__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 pasta = 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 * 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 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, u= nion 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_TIMEOUTS_= 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. That's a good point. > > > > > + > > > > 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 outboun= d 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. 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. > > > > > > > * @syn_retries: SYN retries using exponential backoff timeout > > > > * @syn_linear_timeouts: SYN retries before using exponential back= off 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 code > david AT gibson.dropbear.id.au | minimalist, thank you, not the other wa= y > | around. > http://www.ozlabs.org/~dgibson --=20 Thanks, Yumei Huang