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=eOal432a; 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 C9AAD5A0279 for ; Mon, 18 Aug 2025 19:06:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1755536794; 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=9GNVNDr5hLi9h7vM7piez+P7MsbRw3PFqJl1cFe3UGg=; b=eOal432aQfDh5feYtidXiW6DGwqwnTfe+TssEE8HqZuj7oLq98C8T0rY8Szc4iAqUfGHsv ZuxUa1T4D2E7e5VnmjwGrENnRfbK1SfEWGXBIzlTfTc+C0tEiIREcJ9aPcJoObzzfPQgrW E+vhvSA0on2FooAzp1Sa92f8P1XNl1E= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-223-Z5TWR4wIM-GIu-UxLQUjqQ-1; Mon, 18 Aug 2025 13:06:33 -0400 X-MC-Unique: Z5TWR4wIM-GIu-UxLQUjqQ-1 X-Mimecast-MFC-AGG-ID: Z5TWR4wIM-GIu-UxLQUjqQ_1755536792 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-45a1b0b14daso14774735e9.2 for ; Mon, 18 Aug 2025 10:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755536792; x=1756141592; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9GNVNDr5hLi9h7vM7piez+P7MsbRw3PFqJl1cFe3UGg=; b=ww8azzU6V6tvnAfffQQsgoVzlozfR5G7w/0xYr4dHdlNQj/7q4cZgJfjutoqH0PF9l XMBOxkiJpJSF8hNyo2uf4z3IshpMTE7cQR6E9mZcHfTIA+jBxXAAI7UyrdwvIYY6nd3T ADdD0rhlSYAP7BMAu7u/MNGm8iXO6XTv8XxxQz7KsTHTTsQNdd6gr36OTQVSEjQpeKvs 53OuMKyrAq/Rud+vq2/9kEKPAK83EY9Hpi4KwRRALoEq+yFDGeo03qYOrIovvOhkTW5q AS+x7MCG/V1mU3+/sPHmnOwDjXgS73zw3hG/i22dz5rhizXXj9nxcPKc7MDQdSDegH3d gD8Q== X-Gm-Message-State: AOJu0YyF4+nBO+JktNbFeeZH8cyjthN2PW/J5c0a+//mQcDQ6ApUL7ax H18bx39Iv4r4ShXp/N08SbyWDKNMZKO4V/6Fg6xVt9cK3zfskZt9isXfst8S3tVVv15/GjcRMCm ju9P1IozjvfBpHrZ6Y1awkRof9448Ed+qAA1hXqCtRhDywIOE3wa5bA== X-Gm-Gg: ASbGnctTIEoEB3FXlASSxssLnkCgoI9ghKBvRC7VD2O7VkxQIeCAtsXjBmv9sOlhkBo VpwvlTilTORnBTOEiP3B5gmIir9WY2Ued5JKNqYtERqA1lNqLmKJITSoPsX3KNDIGj9HgRLtQGZ 0uFhOLjieYnsdG9oPOhme4GtVFtE9boHhtaNpFwC6n9O/uaUeo1KXdpqQJGzuDXifAnDUzhxqAZ 2r12IrQJ/MBJGN0KYuBEVKNKUQ5SxAeNyZOycxoQwjnPnbRZUeiZ84xEOevjZauqpLbXOQ7kwBV hLvxF1VK8pXd7vwuF6Z8CzCh1+N5XK9Kzky8E4LjfLhFh1Pk/orop1q55FaJKPQZ+F49 X-Received: by 2002:a05:600c:4451:b0:456:1a87:a6cb with SMTP id 5b1f17b1804b1-45a218590c8mr116804495e9.19.1755536791999; Mon, 18 Aug 2025 10:06:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHOdWZRwuvTKaM0gaUxHnQUY/N8C+mPHk0MozgAKp82TdSseDr6AfDEbJPr650LPXq0zrIDcg== X-Received: by 2002:a05:600c:4451:b0:456:1a87:a6cb with SMTP id 5b1f17b1804b1-45a218590c8mr116804255e9.19.1755536791541; Mon, 18 Aug 2025 10:06:31 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3c0777884e8sm270419f8f.45.2025.08.18.10.06.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Aug 2025 10:06:31 -0700 (PDT) Date: Mon, 18 Aug 2025 19:06:29 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 5/6] tcp: Don't try to transmit right after the peer shrank the window to zero Message-ID: <20250818190629.280f0e0c@elisabeth> In-Reply-To: References: <20250815161042.3606244-1-sbrivio@redhat.com> <20250815161042.3606244-6-sbrivio@redhat.com> 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: oS4tMbaof1ARtpjjbpZYYdH49AJHMpixT08_bxk_6GA_1755536792 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: VSHKQSXRPOMAY2DPYOUW7BCTAEP4XRGI X-Message-ID-Hash: VSHKQSXRPOMAY2DPYOUW7BCTAEP4XRGI 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, Jon Maloy , Paul Holzinger 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 Mon, 18 Aug 2025 12:56:09 +1000 David Gibson wrote: > On Fri, Aug 15, 2025 at 06:10:41PM +0200, Stefano Brivio wrote: > > If the peer shrinks the window to zero, we'll skip storing the new > > window, as a convenient way to cause window probes (which exceed any > > zero-sized window, strictly speaking) if we don't get window updates > > in a while. > > Strictly speaking, not storing the new zero window feels slightly > wrong to me - I wonder if it would be more correct to store the zero > window, but still send window probes as a special case. Yeah, it's wrong but it's not really obvious what value we should use at that point. With a recent kernel version, there would be no problem storing 0, waiting for a window update which will come soon after, and reserve the special case I already added (1 as window size) for zero-window probes, triggered via timer. But without 8c670bdfa58e ("tcp: correct handling of extreme memory squeeze"), and with e2142825c120 ("net: tcp: send zero-window ACK when no memory"), the window update never comes, so we would need to wait for the timer to expire before we send an explicit zero-window probe, which takes a while (two seconds). With this trick, instead, we keep the latest advertised value, which is actually the latest correct value, and retry sending what we were originally sending as soon as we have more data from the socket, which would becomes available quite soon in all the practical cases where the kernel shrinks the window to zero. Maybe we could store zero, and use WINDOW_DEFAULT (14600 bytes) on socket activity. The RFC simply says we need to send zero-window probes at some point, not that we should assume a broken receiver, but unfortunately between e2142825c120 and 8c670bdfa58e it's like that. -- Stefano