From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=PlIwPl/k; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 1EF355A004E for ; Mon, 08 Dec 2025 01:19:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765153172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SpzcQfx3mD54mF8l7+YmSK//cEQeaJCAHNo24ESJbJ0=; b=PlIwPl/kY/+Es9FfbE4WaON7E353l2PTk8MK9fCQyUahXHk++DkbRWIPKsom9HJaZSjRDA c8EJJlOxqPschMUNGwtBPqw5+kzgurzy5i08Tp3Ly3WET1cx9xySkWtNujdgIjGQ8QWDLx GLMQMkU9MJkAwUxWSWuEZNzU+raVjHI= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-247-9YlL0gBiODq2L_sXLXQwHw-1; Sun, 07 Dec 2025 19:19:31 -0500 X-MC-Unique: 9YlL0gBiODq2L_sXLXQwHw-1 X-Mimecast-MFC-AGG-ID: 9YlL0gBiODq2L_sXLXQwHw_1765153170 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-477771366cbso27874685e9.0 for ; Sun, 07 Dec 2025 16:19:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765153170; x=1765757970; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SpzcQfx3mD54mF8l7+YmSK//cEQeaJCAHNo24ESJbJ0=; b=aXklIxcrJeGpzHiWXVkQ8Db5t1dv+LH/Kn+cArD9h1G0Lclng4wsv2ZkAMcBGr/lNx eAo11LJpzngN1cOOuC2h0OSqxi+5piwc95ZOK9UROGaK0nFuvp0lsexIXNdyEQ/eHDgI W7QDWUdmLj8qS2Bz92CHpkTb9XXQysytvNz6IeWYtOae9s+Ykbo6RAaZrY585pERLEGz qhFs6zLga3Fc8B5a1hy6SxwI/jkxuO6cigC4Kzv6JiXhd/DvcukDP2TVs5maO3/i/nJC 9rdgUKYsHagDo/HhXdkAA/GMnsh9sGb5U4F5nrCnMSrWU06pG8TqbzTH4X+61syi1hdS DruQ== X-Gm-Message-State: AOJu0Yx4XsIaaGEJUPZfL5X7yf/WpiBW8rLX2tZdRjgVvChTngWuXfek JT8UIqA4OMAxtsZgUIvhmxJ9bh3tU3nIODETCC78VF39K7LXgVqc3LI8vHHnfONQgt1EW01+aCp JPKZYbBjtLAInrYwxWuzZx35U8pp3xATnmsoJ6oc0XDkZ+29WsjANVxH/jtfyoQ== X-Gm-Gg: ASbGncteSxbspzC8079bC3mtdhX6KZn5TRcPEhQWrTlnbiK7RmWxGRmFckST6DNVgnC 3Yrq9ogNN/DuLfiGgKL7+drgpxy1p/SwSMtS15UjBxAg9nVnXufEtFdSWksDaxg6oV3Xksp7LNP /bnJjpA8DGk3X6ItqvdiM4VfwcecQfsKAxMwkumdgtBuM4gzQ5j07LqTSYE8P7aGzvoCuIuoWSZ P3/DE4g5A0ACvRLTazrz/YJXlJ9V9TSdzU1elYSC2naCNzHWrzrUEKmbQcqEIVmFveHMRkNVfn4 ErsRsixhZ3P6cWvOK0pc366Gus5LCbYlCt6EVZh5CMO9IqW50pITHvF4FH1z729s0MlUhWO06LE P6zzqzTwC/RndUSJybgw/ X-Received: by 2002:a05:600c:500d:b0:477:7b16:5f88 with SMTP id 5b1f17b1804b1-47939df14bcmr53789925e9.6.1765153169597; Sun, 07 Dec 2025 16:19:29 -0800 (PST) X-Google-Smtp-Source: AGHT+IGlOUoyLtuy95K6mcbdxqBHPihH7ujKefkhicFSsXjndSWD+oAcORs9NB2JxY1SH058YpXIQg== X-Received: by 2002:a05:600c:500d:b0:477:7b16:5f88 with SMTP id 5b1f17b1804b1-47939df14bcmr53789865e9.6.1765153169187; Sun, 07 Dec 2025 16:19:29 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4793091c740sm203504355e9.3.2025.12.07.16.19.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Dec 2025 16:19:28 -0800 (PST) Date: Mon, 8 Dec 2025 01:19:27 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 4/8] tcp: Acknowledge everything if sending buffer is less than SNDBUF_BIG Message-ID: <20251208011927.14a4f482@elisabeth> In-Reply-To: References: <20251204074542.2156548-1-sbrivio@redhat.com> <20251204074542.2156548-5-sbrivio@redhat.com> <20251205022012.2acceb8e@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OfVRCH-lL72K7MvmlZn4jA1Y_GA_ano0f6Vf4fMNOLE_1765153170 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: UFFVRTB6BSRFZPEMYIMUGG5GMNCYWK4T X-Message-ID-Hash: UFFVRTB6BSRFZPEMYIMUGG5GMNCYWK4T X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Max Chernoff X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 5 Dec 2025 13:50:15 +1100 David Gibson wrote: > On Fri, Dec 05, 2025 at 02:20:12AM +0100, Stefano Brivio wrote: > > On Fri, 5 Dec 2025 11:08:06 +1100 > > David Gibson wrote: > > > > > On Thu, Dec 04, 2025 at 08:45:37AM +0100, Stefano Brivio wrote: > > > > ...instead of checking if it's less than SNDBUF_SMALL, because this > > > > isn't simply an optimisation to coalesce ACK segments: we rely on > > > > having enough data at once from the sender to make the buffer grow > > > > by means of TCP buffer size tuning implemented in the Linux kernel. > > > > > > > > Use SNDBUF_BIG: above that, we don't need auto-tuning (even though > > > > it might happen). SNDBUF_SMALL is too... small. > > > > > > Do you have an idea of how often sndbuf exceeds SNDBUF_BIG? I'm > > > wondering if by making this change we might have largely eliminated > > > the first branch in practice. > > > > Before this series, or after 6/8 in this series, it happens quite > > often. It depends on the bandwidth * delay product of course, but at 1 > > Gbps and 20 ms RTT we get there in a couple of seconds. > > > > Maybe 1 MiB would make more sense for typical conditions, but I'd defer > > this to a more adaptive implementation of the whole thing. I think it > > should also depend on the RTT, ideally. > > Ok. Adding that context to the commit message might be useful. While trying to add that context I came to two realisations: 1. in the past I used the 'netem' qdisc for convoluted things only, so much that I forgot how simple it can be for the task at hand: $ ./pasta --config-net -I moon0 -- sh -c '/sbin/tc q a dev moon0 root netem delay 1282ms; ping -c1 2600::' PING 2600:: (2600::) 56 data bytes 64 bytes from 2600::: icmp_seq=1 ttl=255 time=1298 ms 2. while there don't seem to be public iperf3 instances on the moon, there are indeed servers in Auckland and Tashkent ...hence v2, which implements the adaptive implementation I was referring to. It's rather simplistic and can/should be improved further but it's a big improvement on the existing situation. -- Stefano