Re: About the behavior of tuning of tcp_reass_maxseg

> On Oct 4, 2023, at 7:21 AM, Cheng Cui <cc@freebsd.org> wrote:
> 
> 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

Then is it better to convert `net.inet.tcp.reass.maxsegments` into a *ratio* `net.inet.tcp.reass.maxsegments_ratio` ?

We can have a default 1/16 (of nmbclusters), and it can be write tunable. Also we can limit it to maximum of 15/16 (of nmbclusters)
so that we can always have free mbufs for connections.

The auto-tuning can still be applied whenever nmbclusters changes.

> 
> 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 <mailto: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
> 
>