Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #88812 > unrolled thread

Bug#1111052: Please increase default UDP buffer size limits

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1111052: Please increase default UDP buffer size limits Josh Triplett <josh@joshtriplett.org> - 2025-08-14 05:20 +0200
    Processed: Re: Please increase default UDP buffer size limits "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-08-20 20:20 +0200
    Bug#1111052: Please increase default UDP buffer size limits Ben Hutchings <ben@decadent.org.uk> - 2025-08-20 20:20 +0200
    Bug#1111052: Backport upstream patch? Josh Triplett <josh@joshtriplett.org> - 2025-10-06 22:50 +0200
      Bug#1111657: Bug#1111052: Backport upstream patch? Salvatore Bonaccorso <carnil@debian.org> - 2025-10-13 08:40 +0200

#88812 — Bug#1111052: Please increase default UDP buffer size limits

Package: linux-sysctl-defaults
Version: 4.14
Severity: wishlist
File: /usr/lib/sysctl.d/50-default.conf
X-Debbugs-Cc: josh@joshtriplett.org

Current uses of QUIC benefit from higher buffer size limits. Please
consider setting:

net.core.rmem_max = 7500000
net.core.wmem_max = 7500000

See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes


-- System Information:
Debian Release: forky/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.16-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

[toc] | [next] | [standalone]

#88943 — Processed: Re: Please increase default UDP buffer size limits

Processing control commands:

> tag -1 moreinfo
Bug #1111052 [linux-sysctl-defaults] Please increase default UDP buffer size limits
Added tag(s) moreinfo.

-- 
1111052: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111052
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#88944

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Wed, 13 Aug 2025 20:11:36 -0700 Josh Triplett <josh@joshtriplett.org>
wrote:
> Package: linux-sysctl-defaults
> Version: 4.14
> Severity: wishlist
> File: /usr/lib/sysctl.d/50-default.conf
> X-Debbugs-Cc: josh@joshtriplett.org
> 
> Current uses of QUIC benefit from higher buffer size limits. Please
> consider setting:
> 
> net.core.rmem_max = 7500000

I can see that it makes sense to increase this to allow increasing the
receive window if the QUIC implementation sets its receive window based
on this, or otherwise to reduce the risk of packets being dropped if
user-space is slow to handle them.

I would like to see a detailed justification for the specific value,
though.

> net.core.wmem_max = 7500000

This seems wrong.  With QUIC the memory for replaying lost packets is
allocated in user-space, so I don't see any need to increase buffering
on the send side.  I think that this would mostly contribute to
bufferbloat.

> See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes

No justification is given there for increasing wmem_max.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.

[toc] | [prev] | [next] | [standalone]

#89494 — Bug#1111052: Backport upstream patch?

Upstream, in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6d4f25888b83
, changed these both to 4MiB (4194304).

Please consider backporting this change.

Thanks,
Josh Triplett

[toc] | [prev] | [next] | [standalone]

#89570 — Bug#1111657: Bug#1111052: Backport upstream patch?

Hi Josh,

On Mon, Oct 06, 2025 at 01:31:50PM -0700, Josh Triplett wrote:
> Upstream, in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6d4f25888b83
> , changed these both to 4MiB (4194304).
> 
> Please consider backporting this change.

We usually wont't take patches from mainline if they are not going to
land in stable series. I think the best course of action if you want
to to see that in a stable series corresponding version is to argue
with upstream why it should be backported upstream to a stable series
as well.

If you do so, can you include us please in CC so we are aware of the
progress?

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web