Re: [PATCH net-next 1/4] tcp: sync MSS after enabling MTU probing on passive connections

[Neal Cardwell]

On Tue, Nov 3, 2026 at 2:09 AM Yongjian Wang via B4 Relay
<devnull+echoowall.gmail.com@xxxxxxxxxx> wrote:
>
> From: Yongjian Wang <echoowall@xxxxxxxxx>
>
> tcp_v4_syn_recv_sock() and tcp_v6_syn_recv_sock() call tcp_sync_mss()
> before MTU probing is enabled, and tcp_init_transfer() enables it later
> without syncing the MSS again.
>
> With net.ipv4.tcp_mtu_probing=2, a passive connection therefore starts
> at the full MSS instead of tcp_base_mss as documented, while an active
> connection starts at tcp_base_mss. This has two visible effects, shown
> here with tcp_base_mss=1024:
>
>  - The MSS drops when the first probe is acknowledged, from 1460 to 1242,
>    although that probe has just shown the path can carry more.
>
>  - On a black hole path the MSS never tries tcp_base_mss. It goes from
>    1460 straight to 512, since MTU probing is already enabled when black
>    hole detection triggers.
>
> Sync the MSS right after tcp_mtup_init(). tcp_sync_mss() only applies
> search_low when MTU probing is enabled, so the other tcp_mtu_probing
> values keep their behaviour.
>
> The Fixes commit kept tcp_mtup_init() in a single place on purpose, so
> sync the MSS next to it instead of moving it back into the
> syn_recv_sock() handlers.
>
> Fixes: 4d83e1773031 ("tcp: delete redundant calls of tcp_mtup_init()")
> Signed-off-by: Yongjian Wang <echoowall@xxxxxxxxx>
> ---
>  net/ipv4/tcp_input.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index e1f2d9765..c13f005b2 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -6760,6 +6760,7 @@ void tcp_init_transfer(struct sock *sk, int bpf_op, struct sk_buff *skb)
>         struct tcp_sock *tp = tcp_sk(sk);
>
>         tcp_mtup_init(sk);
> +       tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
>         icsk->icsk_af_ops->rebuild_header(sk);
>         tcp_init_metrics(sk);
>
>
> --

Functionally this seems correct. But I'm wondering about the
performance impact, and whether there is a way to achieve this without
adding this call to the code path for every connection establishment?

Eric and Kuniyuki, WDYT?

neal