From nobody Thu Sep 28 04:19:15 2023 X-Original-To: freebsd-transport@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Rx0cB5C3yz4vVST for ; Thu, 28 Sep 2023 04:19:22 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Rx0cB4dPLz3cL3 for ; Thu, 28 Sep 2023 04:19:22 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695874762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=VH+SEjO3ieIUxD+L22OFgeD8gA/n94RxoOnxkL2oYCo=; b=HT8J3P9l1GwMaeJdFq73eF0PInACkdyrCdMSm+At759CG4irN3x/Mqy7Mb3AVMgoCJFcnQ 9UHgdIZ/lGc8Bx2X5HRmFcl9EqWd4ggIkocWbDPtN7+d8cZs+rESFopq/KYQAgfiyP0L9K NviEvAYzQbx5CBlBx1MJlcbYqo3cUyXCJJr7I6FO9q2QfWckZaJCgc1V7YMiG6bbrC78dY P2tAPxZH4H2X5ugsowvv03/QehzcKjQ/S2kBwi6IQvXJurbUu+R/HzBRyPxFKk/Wd8q2CY KbTGj1E6BtG8UuZ3Dt1z99GloDRmluJGkn5wBHCRpdkh4weUu/rdZHFGTVEhnQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695874762; a=rsa-sha256; cv=none; b=Ps/h0ZlnTYbwm5mulkhxC32BS2A4KLhcVvgLmGPoJMSovTCKXpssmKqmOu2Ni0Fw92GLix 0l3xyTk90jO47lwj0ljV/sfAexzB9V68U3yX6wMmq+t0L9TOonUr2NsYVcjely6h7wzC7G dskn4/3n/WjLR4tz8m12J2nRH3qctcsdqeL7LCSZn/u8uY/gKMCK8iife/MU5DU3isKKuW ND5f7pxZLtiY3Gf56HPM6IlLtb0HtvbLiNhnX5n+PtgvG6DplY6mQwx023kaVSsTh51htc qYRDUfwmIrA2AatXpawuNKlSvHTgeO05OFEdnUegE2EQD6e15ks+6QgU46ZK/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695874762; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=VH+SEjO3ieIUxD+L22OFgeD8gA/n94RxoOnxkL2oYCo=; b=LT8jqkxzzrbuEWf7vavoW/eo/Jiwx3dTBGXtPx94G4PJBN9uBUopbKPAd784E7RQX/35Z8 gHquD4x7d0lELSA+9GL1TGY+aIXMvo+yOezHEFNfmGyoiqMWPac0viXoCTULltk6atRAYf EhfWH0XwEyjQG7TJ6v5YvxTLZouG1d9e76ozjGQzq2sFU5PSogxuYQHKUNiT0VjzjvF9dt os58L8P8m7x2aomP6VL6bFhPwbg4QOcNV5BiIBPksqD3agk/iKa+0fOQB61szwFGGgQmFx cTZhA/VfXMAFyrEnwMmbwVun5le2O9VbI17X69PLGucpUDr5kxJhV2Lr/H0cHQ== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Rx0cB085Fz1QHM for ; Thu, 28 Sep 2023 04:19:21 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: About the behavior of tuning of tcp_reass_maxseg Message-Id: <38BA3DD9-4EC6-4FD9-8F7D-F6AB998D4A6F@FreeBSD.org> Date: Thu, 28 Sep 2023 12:19:15 +0800 To: freebsd-transport@freebsd.org X-Mailer: Apple Mail (2.3696.120.41.1.4) Hi, I'm recently working on SYSCTLs features. While testing the sysctl knob `net.inet.tcp.reass.maxsegments` I got something weird. When I adjust `kern.ipc.nmbclusters`, the `net.inet.tcp.reass.maxsegments` got 'auto tuned' regardless what I have set (the kernel env) in = `/boot/loader.conf`. The relevant code: ``` static int tcp_reass_maxseg =3D 0; SYSCTL_INT(_net_inet_tcp_reass, OID_AUTO, maxsegments, CTLFLAG_RDTUN, &tcp_reass_maxseg, 0, "Global maximum number of TCP Segments in Reassembly Queue"); tcp_reass_global_init(void) { tcp_reass_maxseg =3D nmbclusters / 16; TUNABLE_INT_FETCH("net.inet.tcp.reass.maxsegments", &tcp_reass_maxseg); tcp_reass_zone =3D uma_zcreate("tcpreass", sizeof (struct = tseg_qent), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); /* Set the zone limit and read back the effective value. */ tcp_reass_maxseg =3D uma_zone_set_max(tcp_reass_zone, tcp_reass_maxseg); ... EVENTHANDLER_REGISTER(nmbclusters_change, tcp_reass_zone_change, NULL, EVENTHANDLER_PRI_ANY); } /* Initialize TCP reassembly queue */ static void tcp_reass_zone_change(void *tag) { /* Set the zone limit and read back the effective value. */ tcp_reass_maxseg =3D nmbclusters / 16; tcp_reass_maxseg =3D uma_zone_set_max(tcp_reass_zone, tcp_reass_maxseg); } ``` The above code shows clearly the current behavior. What I expected is, kernel env has priority to the 'auto tuning', unless the admin requested. So comes some questions. 1. Is the above behavior expected ? 2. Is it desirable to make `net.inet.tcp.reass.maxsegments` write = tunable ? 3. Is it valid to set 0 to `net.inet.tcp.reass.maxsegments` ? IIUC that = will effectually disable TCP reassembly. 4. Then can we introduce a constant `-1` to explicitly enable the 'auto = tuning' feature ? Best regards, Zhenlei