[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADVnQykxV+E6VqsZTSi9pnQNgZ5xFFbdtJTafU_yUShghmjnMA@mail.gmail.com>
Date: Thu, 20 Nov 2025 11:48:05 -0500
From: Neal Cardwell <ncardwell@...gle.com>
To: "He.kai Zhang.zihan" <hk517j@...mail.com>
Cc: edumazet@...gle.com, kuniyu@...gle.com, davem@...emloft.net,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org, dsahern@...nel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp:provide 2 options for MSS/TSO window size: half the
window or full window.
On Thu, Nov 20, 2025 at 11:13 AM He.kai Zhang.zihan <hk517j@...mail.com> wrote:
>
>
> On 2025/11/20 00:43, Neal Cardwell wrote:
> > On Wed, Nov 19, 2025 at 11:30 AM He.kai Zhang.zihan <hk517j@...mail.com> wrote:
> >
> > Please read the following before sending your next patch:
> >
> > https://docs.kernel.org/process/maintainer-netdev.html
> > https://docs.kernel.org/process/submitting-patches.html
> >
> > Rather than attaching patches, please use "git send-email" when
> > sending patches, with something like the following for networking
> > patches:
> >
> > # first check:
> > ./scripts/checkpatch.pl *.patch
> > # fix any issues
> >
> > # then send:
> > git send-email \
> > --to 'David Miller <davem@...emloft.net>' \
> > --to 'Jakub Kicinski <kuba@...nel.org>' \
> > --to 'Eric Dumazet <edumazet@...gle.com>' \
> > --cc 'netdev@...r.kernel.org' *.patch
> >
> > On the specifics of your patch:
> >
> > (1) Can you please send a tcpdump packet trace showing the problem you
> > are trying to solve, and then another trace showing the behavior after
> > your patch is applied?
> >
> > (2) Can you please provide your analysis of why the existing code in
> > tcp_bound_to_half_wnd() does not achieve what you are looking for? It
> > already tries to use the full receive window when the receive window
> > is small. So perhaps all we need is to change the
> > tcp_bound_to_half_wnd() logic to not use half the receive window if
> > the receive window is less than 1 MSS or so, rather than using a
> > threshold of TCP_MSS_DEFAULT?
> >
> > thanks,
> > neal
>
>
> Thank you for your reply! I will submit the patch according to your
> suggestions next time.
>
> soon
> (1) This issue actually occurs on Linux 4.x.x, caused by the function
> tcp_bound_to_half_wnd().
> This function first appeared in 2009 and has never been modified since
> then. Moreover, Linux
> 4.x.x is no longer available on the homepage of www.kernel.org, so I
> assume you probably
> won't accept patches for Linux 4.x.x. Therefore, this patch is based on
> Linux 6.x.x. I will prove
> based on my analysis that this issue has existed for a long time.
> Regarding the tcpdump you
> requested, I will send it to you later for reference.
>
>
> (2) In the current era, when dealing with embedded devices which often
> use the lwIP or uIP
> protocol stacks,MSS is generally around 1460 bytes. However, in the
> tcp_bound_to_half_wnd()
> function, the value of TCP_MSS_DEFAULTis 536U/* IPv4 (RFC1122, RFC2581)
> */. When the peer
> has only 1 MSS (i.e., 1460 bytes), and we want to send 1200 bytes, Linux
> judges that this exceeds
> the 536 threshold and thus segments the data, sending it in two parts
> (the first 730 bytes, and
> the remaining in the second). But Windows 10 sends it in one go. What I
> want is to send it in
> one go. Previously, I considered changing the threshold of
> TCP_MSS_DEFAULT to 1460, which
> seemed convenient and safe, but it doesn’t seem appropriate—this
> threshold originates
> from the RFC 1122 and RFC 2581 standards. What do you think? Is it
> feasible?When the peer's
> receive window is less than or equal to 1 MSS, we can avoid using half
> the window. The
> tcp_bound_to_half_wnd() function introduces a variable parameter mss_now
> and then
> performs a comparison. I'll modify and test this approach later.
Yes, something like that. I agree that when the peer's receive window
is less than or equal to 1 MSS, it seems to make sense to avoid using
half the receive window.
Please keep in mind the tcp_bound_to_half_wnd() comment:
* On the other hand, for extremely large MSS devices, handling
* smaller than MSS windows in this way does make sense.
thanks,
neal
Powered by blists - more mailing lists