Re: About the behavior of tuning of tcp_reass_maxseg

Here are my short answers based on my understanding of the two
relevant commits:
commit 12e2e970515339729eccebdc751afb97fa0af6fa
Author: Andre Oppermann <andre@FreeBSD.org>
Date:   Tue Feb 24 15:27:41 2004 +0000

commit 4f590175b7f3a4efecdd28ffd3306d30724d32c9
Author: Paul Saab <ps@FreeBSD.org>
Date:   Fri Apr 21 09:25:40 2006 +0000


> So comes some questions.
>
> 1. Is the above behavior expected ?
>
Yes

2. Is it desirable to make `net.inet.tcp.reass.maxsegments` write tunable ?
>
No, as it is indirectly tuned by nmbclusters. If it is writable, the
tcp_reass_zone has to be re-limited, which does not seem to be necessary.

3. Is it valid to set 0 to `net.inet.tcp.reass.maxsegments` ? IIUC that
> will effectually disable TCP reassembly.
>
Yes, if you mean set 0 to the tunable `net.inet.tcp.reass.maxsegments` in
/boot/loader.conf. I tested it with 0, and it looks like the system booted
well. But disabling it is not recommended as it conflicts with the protocol
principle.

4. Then can we introduce a constant `-1` to explicitly enable the 'auto
> tuning' feature ?

I don't think it is necessary.

Best Regards,
Cheng Cui


On Thu, Sep 28, 2023 at 12:19 AM Zhenlei Huang <zlei@freebsd.org> wrote:

> 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 = 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 = nmbclusters / 16;
>         TUNABLE_INT_FETCH("net.inet.tcp.reass.maxsegments",
>             &tcp_reass_maxseg);
>         tcp_reass_zone = 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 = 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 = nmbclusters / 16;
>         tcp_reass_maxseg = 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
>
>
>