From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Eric Dumazet <edumazet@google.com>,
Neal Cardwell <ncardwell@google.com>,
Willem de Bruijn <willemb@google.com>
Cc: netdev@vger.kernel.org, David Ahern <dsahern@kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: advertise TCP MSS from the configured MTU, not the learned PMTU
Date: Fri, 14 Aug 2026 18:42:47 +0800 [thread overview]
Message-ID: <cede3131-202a-4468-b848-f3ed2e721c72@linux.dev> (raw)
In-Reply-To: <CANn89iJ-2Z5eFZKRAWS_MxVosr8Xe76k-P2djBX+JVfsH57heA@mail.gmail.com>
On 8/14/26 5:21 PM, Eric Dumazet wrote:
> On Fri, Aug 14, 2026 at 8:36 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>> The MSS a host puts in its SYN tells the peer how big a segment it may
>> send us. Right now we can shrink it with a PMTU we learned on our own
>> send path, which is the wrong direction entirely.
>>
>> On asymmetric paths this bites - think DSR load balancers, where the
>> request side goes through a smaller-MTU overlay. We learn a small PMTU
>> going out, then advertise a small MSS, and the peer stays capped for the
>> whole connection even though its path back to us is wide. MSS only shows
>> up in the SYN and never grows back.
>>
>> On symmetric paths we lose nothing by dropping it either: the peer runs
>> its own PMTU discovery and usually already knows the real path MTU.
>>
>> So work out the advertised MSS from the configured route or device MTU
>> and ignore the learned PMTU. Our send side is unchanged, still clamped by
>> tcp_current_mss(). Add ip_dst_mtu_configured()/ip6_dst_mtu_configured()
>> and use them from the two default_advmss() paths.
>>
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> LGTM, but this probably needs Fixes: tags and should be sent to net tree.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Fixes: 164a5e7ad531 ("ipv4: ipv4_default_advmss() should use route mtu")
> Cc: stable@vger.kernel.org
>
> I added the following packetdrill test, please add it in a series.
>
> commit f0c619ca446b669c48b5c2e2c78e23af1a0850b6
> Author: Eric Dumazet <edumazet@google.com>
Thanks Eric, I will do it after cold time.
prev parent reply other threads:[~2026-08-14 10:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 6:35 [PATCH net-next] net: advertise TCP MSS from the configured MTU, not the learned PMTU Jiayuan Chen
2026-08-14 9:21 ` Eric Dumazet
2026-08-14 10:42 ` Jiayuan Chen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cede3131-202a-4468-b848-f3ed2e721c72@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.