From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7897D1F4C8C for ; Sun, 22 Mar 2026 16:32:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774197156; cv=none; b=mxmV2GGo86g1KSknQCOc00QhynHYvcCOEF/DZGK4r+blIACApJtyiRDyKCqEGi95YvASYXfuq7VMfonPYyNhpahDHqY6dC8L8kRYeTh3pyf1Vt8Lbqps2AHQK29/IGC5E5feoIGblRu61wegBAv6QsElOQ7k8t7mdIIaUs45llA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774197156; c=relaxed/simple; bh=86onXyr0j3zbZeSmMOrcZL7rO4mR+xnzbZPSaKqPMZk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gHK9OkR+qSZxtFU8RfLHL5uVwjKVMFe2lM5HXiiB8ykfT2pS9i3yBCJQJ7/JZa+hCiUHVSI8lOMplAY3YUT7nZ1b4vRDNk/LHla4+JsQlCbRrvL5vP6AcKKsf0HixM/FY+DUlG2yJSWS9bHxurzAb2BXBtwZtD2ssOQv2qMFYU0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=mLXGTRzt; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="mLXGTRzt" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-486fb14227cso35941385e9.3 for ; Sun, 22 Mar 2026 09:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774197154; x=1774801954; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=qtYGdmkqWu+PK4AKFpilD0ArImchmB31I1UOjs7lkVw=; b=mLXGTRztuJeVnlspHaQD7y7TyWJYSlb4M9LZaYnjzMPW/Ytl+2WmX2d1gIGeMpXQkt rw+7HD0WnKuQMNKcOD4k1R4y2vlxezbHX1Dbm7THCXbAjMAc+1Z/snuE8WWg1kSrfxds 3XkTcvK1MqYCWSiWVnR1s3pCCjS6A+rr2oCx27MjRD+UcAUrh/dw7AiKpAAlmWEj6PvR 70PTgE+w/aX4/Yk9+XG0bn2Me6mBYUaavY3YszSV6osa1IkAvvRH9BGjOAZtQoVU+tW3 zJkuKnVd/wUrs7XaIN1ubUagOGWpeO09P1NRWBj8dtoFKlkGTbT7lWQhbNUPJdreX1Pp N9JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774197154; x=1774801954; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qtYGdmkqWu+PK4AKFpilD0ArImchmB31I1UOjs7lkVw=; b=IrgMs/3AbvAH5jyDsmxy2+1pRhaQzgEj+m9n3zvI/ikemdsn/HoE0jinPJQR5Xr/IW ytdgQ9cWGOen7iqKPWXcEtNWwt9Y6EoVcLsl2h3Z+Ji/fkj5uXHdK1Wlkphwydy3vcjI WOxNJx+0INrmtIKjS9DdlgZEXkz6s9392RTlN/TDQvktDHGXfg83a5UU15bpYwHCmrdo UdRPO4/cOMmeuZUSdeCm6gQL3HMp2mgAA9ngu3bwl1ziaf5AkfxD0tZWucZvJ6osVWaK 4JXUZjE1keStowZXrQuGEMThNxwbN/PMERIBVWEc2/vN8fzARycr+xjuLGwQaqC9uZGn 06JA== X-Forwarded-Encrypted: i=1; AJvYcCUTjD1xzWp2HVJfbEDPi8ZFR8g7XoTFyFYSofj5Uit/aFSqPlrJCNfDaDXEZHgHz7/LisPkZLE191ZmQ4E=@vger.kernel.org X-Gm-Message-State: AOJu0YxMX37P0GrpMB4hBRv1STceyP4oV3i8oHi/dDN6b79Zy7fJJyHV w7TQN9fPQok4PtCNnM3icC9HVZex+gm0aiESJ/1vuahw2jbI0m2r7QxN X-Gm-Gg: ATEYQzyap8Ob7k6QfPw/RFVHvRxPIShvNlALnfqSWam5J2jcJArm1+S5IvWbewzdqgX rrvJA6WmIeNTQflwVFbU0oA2o6ZmXAxQUbDYHktmhtRjWSURRwJugKPP+UQAy+z9VSZxE+zXqqt 9gkDLW+V07N3cv0iyrK8vGUzfVf+Rb0PBLvVP3vasndLFuS3D46Vk95WHUom0HQGPBZ973V7Yyw OdOjaZjF8OnAbJPVzLT4su27bTMhl/8+ew2DvQz90lpjjLeLhq+DFBsEoPswRk5Br3RVY4FX4qj Hfx2toxCXOrRzuOxR/tZ7od3FIort1YiS2/H3tZNYPoeVTJcN5v93u8fs+q5OsnZq3ryhLGHD/H iPMAy2xFJhA9iq9bQScPMi72tVpnrvRjQxIKp+Bm2uel2norDxBrgmTF994KqCLLwjgYA+ruPT+ NkayE4GQdbT2E4+ZfHF/6dNI68IsG9oAx+G3n4s0KEQ+nuOjdY3AGLr8dLFgZHwQ== X-Received: by 2002:a05:600c:5250:b0:485:304a:58cd with SMTP id 5b1f17b1804b1-486fedab733mr131868455e9.4.1774197153561; Sun, 22 Mar 2026 09:32:33 -0700 (PDT) Received: from gandalf.schnuecks.de (p5b2e2ef5.dip0.t-ipconnect.de. [91.46.46.245]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486f8b949e1sm478665705e9.9.2026.03.22.09.32.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Mar 2026 09:32:33 -0700 (PDT) Received: by gandalf.schnuecks.de (Postfix, from userid 500) id 6B4903054C7C; Sun, 22 Mar 2026 17:32:32 +0100 (CET) Date: Sun, 22 Mar 2026 17:32:32 +0100 From: Simon Baatz To: Wesley Atwell Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, horms@kernel.org, kuba@kernel.org, kuniyu@google.com, ncardwell@google.com, pabeni@redhat.com, shuah@kernel.org Subject: Re: [PATCH net-next 3/3] selftests: packetdrill: cover scaled rwnd quantization slack Message-ID: References: <20260317065137.1533226-1-atwellwea@gmail.com> <20260317065137.1533226-4-atwellwea@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260317065137.1533226-4-atwellwea@gmail.com> Hi Wesley, On Tue, Mar 17, 2026 at 12:51:37AM -0600, Wesley Atwell wrote: > Add a packetdrill reproducer for the scaled no-shrink quantization case. > > The sequence leaves slightly more than 84 scaled units of backed credit > after one skb is drained. The buggy ALIGN() path rounds that up and > exposes a fresh extra unit, so the wire-visible window becomes 85. I ran this test on current net-next with assertions on all advertised windows. The following passes: ... +0 < P. 10001:11024(1023) ack 1 win 257 * > . 1:1(0) ack 11024 win 85 // Free one skb, then force an outbound packet so the current advertised // window is observable both on the wire and via TCP_INFO. +0 read(4, ..., 10000) = 10000 +0 write(4, ..., 1) = 1 * > P. 1:2(1) ack 11024 win 85 +0 %{ assert (tcpi_rcv_wnd >> 10) == 85, tcpi_rcv_wnd }% // Queue a tiny OOO skb. This should not create fresh sender-visible credit // on the next ACK after the first post-drain window update. +0 < P. 12024:12025(1) ack 2 win 257 * > . 2:2(0) ack 11024 win 85 +0 %{ assert (tcpi_rcv_wnd >> 10) == 85, tcpi_rcv_wnd }% I do not see an “extra unit” after draining; the sender-visible window stays at 85 throughout. In this flow the receive window is limited by rcv_ssthresh (86286) and not by memory (free_space > 92000). The effect of the change looks to be that the previous code settles at rcv_ssthresh rounded up, while the patched code settles at rcv_ssthresh rounded down. The choice in the current code seem to be explicit, in the shrink_window_allowed branch we have: if (free_space > tp->rcv_ssthresh) { free_space = tp->rcv_ssthresh; /* new window should always be an exact multiple of scaling factor * * For this case, we ALIGN "up" (increase free_space) because * we know free_space is not zero here, it has been reduced from * the memory-based limit, and rcv_ssthresh is not a hard limit * (unlike sk_rcvbuf). */ free_space = ALIGN(free_space, (1 << tp->rx_opt.rcv_wscale)); } Thus, we explicitly round up when we are constrained by rcv_ssthresh. As Paolo noted, once free_space gets smaller we already round down, so the current behavior appears to be: round up while there is headroom (possibly constrained by rcv_ssthresh), and round down once memory starts to get tight, which makes sense IMHO. Given that, this test case demonstrates that the new code now expects rounding down even when there is ample memory, but it does not show a concrete improvement in the situation the patch is meant to fix (i.e. a case where the current rounding-up behavior actually hurts). > Then queue a tiny OOO skb so the next ACK re-runs the no-shrink path > after a small receive-memory change without advancing rcv_nxt. With the > fix in place, both ACKs keep the sender-visible window at 84. And without it, both ACKs keep the sender-visible window at 85. > This provides fail-before/pass-after coverage for both the immediate > quantization bug and the follow-on ACK transition that reuses the stored > window state. > > Signed-off-by: Wesley Atwell > --- > .../packetdrill/tcp_rcv_quantization_credit.pkt | 45 ++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > create mode 100644 tools/testing/selftests/net/packetdrill/tcp_rcv_quantization_credit.pkt > > diff --git a/tools/testing/selftests/net/packetdrill/tcp_rcv_quantization_credit.pkt b/tools/testing/selftests/net/packetdrill/tcp_rcv_quantization_credit.pkt > new file mode 100644 > index 0000000000000000000000000000000000000000..8ea96281b601f2d161cfd84967cad91cedb03151 > --- /dev/null > +++ b/tools/testing/selftests/net/packetdrill/tcp_rcv_quantization_credit.pkt > @@ -0,0 +1,45 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +--ip_version=ipv4 Is there a particular reason to restrict this to IPv4 only? > +--mss=1000 > + > +`./defaults.sh > +sysctl -q net.ipv4.tcp_moderate_rcvbuf=0 > +sysctl -q net.ipv4.tcp_shrink_window=0 > +sysctl -q net.ipv4.tcp_rmem="4096 131072 $((32*1024*1024))"` > + > +// Exercise the scaled no-shrink path in __tcp_select_window(). > +// The sequence below leaves slightly more than 84 scaled units of backed > +// credit after one skb is drained. The buggy ALIGN() path rounds that up and I'd drop the "buggy ALIGN() path" wording in the comment. If the change lands, there is no longer such a path, and the comment should just describe the behavior the test is checking. > +// exposes a fresh extra unit; the fixed path keeps the sender-visible window > +// at 84. Then queue a tiny OOO skb so the next ACK re-runs the no-shrink > +// path after a small receive-memory change without advancing rcv_nxt. - Simon -- Simon Baatz