Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

[Jakub Kicinski]

On Tue, 13 May 2025 19:39:19 +0000 Eric Dumazet wrote:
> Last change to tcp_rmem[2] happened in 2012, in commit b49960a05e32
> ("tcp: change tcp_adv_win_scale and tcp_rmem[2]")
> 
> TCP performance on WAN is mostly limited by tcp_rmem[2] for receivers.
> 
> After this series improvements, it is time to increase the default.

I think this breaks the BPF syncookie test, Kuniyuki any idea why?

https://github.com/kernel-patches/bpf/actions/runs/15016644781/job/42196471693

Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

[Kuniyuki Iwashima]

From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 14 May 2025 13:24:22 -0700
> On Tue, 13 May 2025 19:39:19 +0000 Eric Dumazet wrote:
> > Last change to tcp_rmem[2] happened in 2012, in commit b49960a05e32
> > ("tcp: change tcp_adv_win_scale and tcp_rmem[2]")
> > 
> > TCP performance on WAN is mostly limited by tcp_rmem[2] for receivers.
> > 
> > After this series improvements, it is time to increase the default.
> 
> I think this breaks the BPF syncookie test, Kuniyuki any idea why?
> 
> https://github.com/kernel-patches/bpf/actions/runs/15016644781/job/42196471693

It seems ACK was not handled by BPF at tc hook on lo.

ACK was not sent or tcp_load_headers() failed to parse it ?
both sounds unlikely though.

Will try to reproduce it.

Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

[Kuniyuki Iwashima]

From: Kuniyuki Iwashima <kuniyu@amazon.com>
Date: Wed, 14 May 2025 13:53:39 -0700
> From: Jakub Kicinski <kuba@kernel.org>
> Date: Wed, 14 May 2025 13:24:22 -0700
> > On Tue, 13 May 2025 19:39:19 +0000 Eric Dumazet wrote:
> > > Last change to tcp_rmem[2] happened in 2012, in commit b49960a05e32
> > > ("tcp: change tcp_adv_win_scale and tcp_rmem[2]")
> > > 
> > > TCP performance on WAN is mostly limited by tcp_rmem[2] for receivers.
> > > 
> > > After this series improvements, it is time to increase the default.
> > 
> > I think this breaks the BPF syncookie test, Kuniyuki any idea why?
> > 
> > https://github.com/kernel-patches/bpf/actions/runs/15016644781/job/42196471693
> 
> It seems ACK was not handled by BPF at tc hook on lo.
> 
> ACK was not sent or tcp_load_headers() failed to parse it ?
> both sounds unlikely though.
> 
> Will try to reproduce it.

I hard-coded the expected TCPOPT_WINDOW to be 7, and this
series bumps it to 10, so SYN was dropped as invalid.

This fixes the failure, and I think it's not a blocker.

---8<---
diff --git a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
index eb5cca1fce16..7d5293de1952 100644
--- a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
+++ b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
@@ -294,7 +294,9 @@ static int tcp_validate_sysctl(struct tcp_syncookie *ctx)
 	    (ctx->ipv6 && ctx->attrs.mss != MSS_LOCAL_IPV6))
 		goto err;
 
-	if (!ctx->attrs.wscale_ok || ctx->attrs.snd_wscale != 7)
+	if (!ctx->attrs.wscale_ok ||
+	    !ctx->attrs.snd_wscale ||
+	    ctx->attrs.snd_wscale >= BPF_SYNCOOKIE_WSCALE_MASK)
 		goto err;
 
 	if (!ctx->attrs.tstamp_ok)
---8<---

Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

[Jakub Kicinski]

On Wed, 14 May 2025 14:20:05 -0700 Kuniyuki Iwashima wrote:
> > It seems ACK was not handled by BPF at tc hook on lo.
> > 
> > ACK was not sent or tcp_load_headers() failed to parse it ?
> > both sounds unlikely though.
> > 
> > Will try to reproduce it.  
> 
> I hard-coded the expected TCPOPT_WINDOW to be 7, and this
> series bumps it to 10, so SYN was dropped as invalid.
> 
> This fixes the failure, and I think it's not a blocker.
> 
> ---8<---
> diff --git a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> index eb5cca1fce16..7d5293de1952 100644
> --- a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> +++ b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> @@ -294,7 +294,9 @@ static int tcp_validate_sysctl(struct tcp_syncookie *ctx)
>  	    (ctx->ipv6 && ctx->attrs.mss != MSS_LOCAL_IPV6))
>  		goto err;
>  
> -	if (!ctx->attrs.wscale_ok || ctx->attrs.snd_wscale != 7)
> +	if (!ctx->attrs.wscale_ok ||
> +	    !ctx->attrs.snd_wscale ||
> +	    ctx->attrs.snd_wscale >= BPF_SYNCOOKIE_WSCALE_MASK)
>  		goto err;
>  
>  	if (!ctx->attrs.tstamp_ok)

Awesome, could you submit officially? As soon as your fix is in
patchwork I can return Eric's series into the testing branch.

Re: [PATCH net-next 11/11] tcp: increase tcp_rmem[2] to 32 MB

[Kuniyuki Iwashima]

From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 14 May 2025 14:26:20 -0700
> On Wed, 14 May 2025 14:20:05 -0700 Kuniyuki Iwashima wrote:
> > > It seems ACK was not handled by BPF at tc hook on lo.
> > > 
> > > ACK was not sent or tcp_load_headers() failed to parse it ?
> > > both sounds unlikely though.
> > > 
> > > Will try to reproduce it.  
> > 
> > I hard-coded the expected TCPOPT_WINDOW to be 7, and this
> > series bumps it to 10, so SYN was dropped as invalid.
> > 
> > This fixes the failure, and I think it's not a blocker.
> > 
> > ---8<---
> > diff --git a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> > index eb5cca1fce16..7d5293de1952 100644
> > --- a/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> > +++ b/tools/testing/selftests/bpf/progs/test_tcp_custom_syncookie.c
> > @@ -294,7 +294,9 @@ static int tcp_validate_sysctl(struct tcp_syncookie *ctx)
> >  	    (ctx->ipv6 && ctx->attrs.mss != MSS_LOCAL_IPV6))
> >  		goto err;
> >  
> > -	if (!ctx->attrs.wscale_ok || ctx->attrs.snd_wscale != 7)
> > +	if (!ctx->attrs.wscale_ok ||
> > +	    !ctx->attrs.snd_wscale ||
> > +	    ctx->attrs.snd_wscale >= BPF_SYNCOOKIE_WSCALE_MASK)
> >  		goto err;
> >  
> >  	if (!ctx->attrs.tstamp_ok)
> 
> Awesome, could you submit officially? As soon as your fix is in
> patchwork I can return Eric's series into the testing branch.

For sure, will post a patch shortly.