Re: (2) [net-next,v3] ipv6: shorten reassembly timeout under fragment memory pressure
From: Eric Dumazet <edumazet@google.com>
Date: 2026-02-12 07:17:09
Also in:
netfilter-devel
On Thu, Feb 12, 2026 at 1:22 AM 배석진 [off-list ref] wrote:
quoted
On Wed, Feb 11, 2026 at 4:11 PM Fernando Fernandez Mancera [off-list ref] wrote:quoted
On 2/11/26 11:32 AM, 배석진 wrote:quoted
Changes in v3: - Fix build bot error and warnings - baseline update From c7940e3dd728fdc58c8199bc031bf3f8f1e8a20f Mon Sep 17 00:00:00 2001 From: Soukjin Bae <redacted> Date: Wed, 11 Feb 2026 11:20:23 +0900 Subject: [PATCH] ipv6: shorten reassembly timeout under fragment memory pressure Under heavy IPv6 fragmentation, incomplete fragment queues may persist for the full reassembly timeout even when fragment memory is under pressure. This can lead to prolonged retention of fragment queues that are unlikely to complete, causing newly arriving fragmented packets to be dropped due to memory exhaustion. Introduce an optional mechanism to shorten the IPv6 reassembly timeout when fragment memory usage exceeds the low threshold. Different timeout values are applied depending on the upper-layer protocol to balance eviction speed and completion probability. Signed-off-by: Soukjin Bae <redacted>Hello, isn't this what net.ipv6.ip6frag_time does? In addition, the situation you described could be overcome by increasing the memory thresholds at net.ipv6.ip6frag_low_thresh and net.ipv6.ip6frag_high_thresh. Please, let me know if I am missing something.Also : 1) net-next is closed. Please read Documentation/process/maintainer-netdev.rst 2) We do not send 3 versions of a patch in the same day. Please read Documentation/process/maintainer-netdev.rst 3) What about IPv4 ? 4) Only the first fragment contains the 'protocol of the whole datagram', and fragments can be received in any order. 5) We do not add a MAINTAINER entry for such a patch, sorry.Hello, Regarding about net.ipv6.ip6frag_time and low/high_thresh: The issue we are addressing currently occurs due to a large volume of mDNS traffic from WiFi APs. As a temporary measure, we increased the high_thresh value to accommodate the traffic. However, UDP traffic such as mDNS cannot recover once a fragment stream is lost, leading to wasted memory. Therefore, this patch is intended to make more efficient use of the currently allocated fragment memory by shortening the reassembly timeout under memory pressure. Also, we tend to avoid changing the global value of ip6frag_time to preserve existing behavior. This is why I added new config too. Regarding others: 1, 2) net-next is closed and multiple patch I apologize for the oversight regarding the net-next status and the frequent submissions. I was tried to fix CI build failures. I will follow the documented guidance going forward. 3) What about IPv4? The issue was primarily observed in IPv6-dominant IMS environments, which was the initial focus. However, I agree that the same memory management logic is beneficial for IPv4. I will include IPv4 support in the next version to provide a unified solution. 4) Only the first fragment contains the 'protocol of the whole datagram'. You are correct. I will update the logic to store the L4 protocol information once the first fragment is received, and only then apply the adjusted timeout. If the first fragment is lost, the adjusted timer will not be triggered, but this is acceptable as a partial case.
I do not think we will accept a patch trying to 'fix' reassembly. This is fundamentally not fixable. I can tell you that in crowded wifi environments, I have seen delays of 30 seconds (and more) to complete a datagram of only 2 fragments. Your default settings are not viable. If you depend on receiving fragments, change the existing tunables. Instead of : /proc/sys/net/ipv6/ip6frag_high_thresh:4194304 (4 MB) /proc/sys/net/ipv6/ip6frag_low_thresh:3145728 (3 MB) /proc/sys/net/ipv6/ip6frag_time:60 Use: /proc/sys/net/ipv6/ip6frag_high_thresh:104857600 (100 MB) /proc/sys/net/ipv6/ip6frag_low_thresh:78643200 (75 MB) /proc/sys/net/ipv6/ip6frag_time:60 Of course, avoiding fragments is the right solution. https://datatracker.ietf.org/doc/html/rfc6762#section-17 TCP should avoid using frags by default.