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=xKgc0zyX; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id F05675A0965 for ; Mon, 10 Nov 2025 05:26:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1762748757; bh=+ZfRrm3krxW59SdK/OEMz5ejmHUGo1exfinfS6APHPk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=xKgc0zyX7BPu06sl0s9c/ikQM74DdmW54p/hjziE72P0IzwwFKR/GcycIfeoL8AyY ItKB1YetHAcK3QAjGh6PnVwfOPMM2LnI+F322tG8EdM7OG1I2RUUo+ZaroTiAea8Wi 3q19RO7gD3NUxQ+J5VIoDSVb77H0O9Eg/rd0k//V5jBIWTchGCaFc6G1WmGodRvefg adfxv4K9lwneJHZTZRs4pJlnJJnvfnplsXLQJfSw+EVjJkRSd5T9t6fZdL94X0H2bn a8JzJfws/CfjcxmVWLcvLSvElfVq5ZhHFbPSh49ye6j1lVb4fx9rZRaxqJsor6E71Y B1XPMnrbI/NPQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4d4c6Y51RYz4wCy; Mon, 10 Nov 2025 15:25:57 +1100 (AEDT) Date: Mon, 10 Nov 2025 15:25:53 +1100 From: David Gibson To: Yumei Huang Subject: Re: [PATCH v7 3/5] tcp: Resend SYN for inbound connections Message-ID: References: <20251031054242.7334-1-yuhuang@redhat.com> <20251031054242.7334-4-yuhuang@redhat.com> <20251104054233.1dec4eb6@elisabeth> <20251105080057.3c4a61b9@elisabeth> <20251107110542.73016350@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4Kcqrc8DEWgn14Oj" Content-Disposition: inline In-Reply-To: Message-ID-Hash: QQTQ5AAB6RCXINU24BLWHVBQ42UXDTCD X-Message-ID-Hash: QQTQ5AAB6RCXINU24BLWHVBQ42UXDTCD 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, Laurent Vivier 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: --4Kcqrc8DEWgn14Oj Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2025 at 10:52:05AM +0800, Yumei Huang wrote: > On Fri, Nov 7, 2025 at 6:05=E2=80=AFPM Stefano Brivio wrote: > > > > On Fri, 7 Nov 2025 17:56:54 +0800 > > Yumei Huang wrote: > > > > > On Wed, Nov 5, 2025 at 3:01=E2=80=AFPM Stefano Brivio wrote: > > > > > > > > On Wed, 5 Nov 2025 15:24:44 +1100 > > > > David Gibson wrote: > > > > > > > > > On Tue, Nov 04, 2025 at 05:42:33AM +0100, Stefano Brivio wrote: > > > > > > On Fri, 31 Oct 2025 13:42:40 +0800 > > > > > > Yumei Huang wrote: > > > > > [snip] > > > > > > > +/** > > > > > > > + * tcp_get_rto_params() - Get host kernel RTO parameters > > > > > > > + * @c: Execution context > > > > > > > +*/ > > > > > > > +void tcp_get_rto_params(struct ctx *c) > > > > > > > +{ > > > > > > > + intmax_t tcp_syn_retries, syn_linear_timeouts; > > > > > > > + > > > > > > > + 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_DE= FAULT); > > > > > > > > > > > > I think this is a bit hard to read. Now: > > > > > > > > > > > > tcp_syn_retries =3D read_file_integer(TCP_SYN_RETRIES, > > > > > > TCP_SYN_RETRIES_DEFAULT= ); > > > > > > syn_linear_timeouts =3D read_file_integer(TCP_SYN_LINEAR_TI= MEOUTS, > > > > > > TCP_SYN_LINEAR_TIME= OUTS_DEFAULT); > > > > > > > > > > > > would be a bit closer to the coding style we're adopting, but I= wonder: > > > > > > > > > > > > - does read_file_integer() really need to have "integer" in the= name? > > > > > > > > > > > In a language where integers are called 'int', perhaps > > > > > > read_file_int() is clear enough? > > > > > > > > > > I think the idea is that read_file_integer() can be used for any > > > > > (signed) integer type (with range checking performed after the ca= ll). > > > > > read_file_int() might suggest it reads exactly an 'int', not anyt= hing > > > > > bigger or smaller. > > > > > > > > Oh, I see. It could be read_file_num() then, even if it's slightly = less > > > > accurate, or it can even remain read_file_integer(). If something l= ike > > > > this: > > > > > > > > v =3D read_file_integer(SYN_RETRIES, SYN_RETRIES_DEFAULT); > > > > c->tcp.tcp_syn_retries =3D MIN(v, UINT8_MAX); > > > > > > > > v =3D read_file_integer(SYN_LINEAR_TIMEOUTS, SYN_LINEAR_TIM= EOUTS_DEFAULT); > > > > c->tcp.syn_linear_timeouts =3D MIN(v, UINT8_MAX); > > > > > > > > fits 80 columns, I'm taking it as a sign that the function name isn= 't > > > > exceedingly long. No particular preference from me. > > > > > > The longest line just exceeds 80 columns. > > > > No, why? It's 80 columns, look: > > > > v =3D read_file_integer(SYN_LINEAR_TIMEOUTS, SYN_LINEAR_TIMEOUT= S_DEFAULT); > > 01234567890123456789012345678901234567890123456789012345678901234567890= 123456789 >=20 > You are right. Somehow I counted 81 columns. Then I will keep the name > as it is. (To me, read_file_num() sounds like it can read any kind of > number.) I also slightly prefer read_file_integer(). --=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 --4Kcqrc8DEWgn14Oj Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkRaUYACgkQzQJF27ox 2GedmA//ZXl7zLRmMETYlds7snkG504RdolpK/D0naeT8JbxX0delMRm1k07Efri OPcn6LAzGuGLByLJInQRqZr67m3Pa9f1hoosHICwEEkcENzj9YPZMX71wnzfbh/D xxfyIJD8fhknFw0t49LEAVGBBH2aQdaBobPcfggVTqoExIUa+j+kgvDGuAeV69WZ pk6IaQgeRUA2pFUZO2lhCVSHWZG5LyrixzegWDQKD28Hge1Y4keHjLTVntPMQ0nM BKi87qhf2DXD0mtEU+cJhzwv9U85yjm6iib43Gpm0/HQ1RRbKKPXCLoH6R+g8//N DWrOL3ZCw//pE2Cf1zKxYSyyxby8NiWc7lrDkPOsbv7m3rL7eM2Q+v7O3AMFQPJu G/0fUfV2IAfy/eCApunSyETMTT6HeTzmsgX/XquBbi/xDeSq5XesOzOjyajv/Z11 1TtLrvwP3GnBnChTXPp6ZFsCLITxnEvanFz/oPl9KSrtDE6PR95tlZFEjcruh/TI KvMWF3gBQO74EjgwrSUYqpLv/21OMAd8zjRdSt4aGE3Zxa3h7WT0+zpe/r91DDWe A8voZuOU2QM42ewlORaEcaGg+WQnx63EPJ05rgd3UbdqZtaoOUnLnyaMwxMwkNgp PZRKqHryfxeLDPMsub64DmW7Iu6y7GWJH5s52modMbMQP/TVmYg= =U/gR -----END PGP SIGNATURE----- --4Kcqrc8DEWgn14Oj--