From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=HBF+CnX4; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 722505A004E for ; Thu, 16 Jan 2025 22:14:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737062070; 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=7z8l1QASAX3+WUul/0208u2RaIVfX2aLywUuLDLRt3Q=; b=HBF+CnX4avzcvL7RnwVCD2EuySeU6A1pp3tHnmAwUWbQQZlPqQN1ZkS9B+4BUBpNECvDBW ixA+2xNiTGEYihBC8KLOSmr2K2DmbSvwmNNoYcnu86TfYBzbQtA+rgS48WWGzGaI/oswuc FZ/zyoNMZrzjpWHqzZky6rrToH3TpIM= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-466-vQIhDpL7PhSXlWUpFlRDJQ-1; Thu, 16 Jan 2025 16:14:29 -0500 X-MC-Unique: vQIhDpL7PhSXlWUpFlRDJQ-1 X-Mimecast-MFC-AGG-ID: vQIhDpL7PhSXlWUpFlRDJQ Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-385ed79291eso1187773f8f.0 for ; Thu, 16 Jan 2025 13:14:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737062067; x=1737666867; 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=7z8l1QASAX3+WUul/0208u2RaIVfX2aLywUuLDLRt3Q=; b=VyzW1Y4OaLMz/ISiPPVnuIIKVDGZX8FhIVO/VO4Bbl8MzKDqJaT70o8rTkIa8k5OUM 8ts681LPmEQNaaGQDc0LsaEJj+4zrSy0RdPqXBdxwrJ4RsZ3syM9vXtSynUI5wAwIhlb 1p1HBUZtqxLET5Z9qLFHAP78wbysKUEE5rN4hS68BO2MZy8rx9ssFZ5WpCQ+IfHJG92k NvfFVq8PkIJEK/5xm2poXdy96MvK242WAE41BCdgD51LXmYeJPQ/fHAUBgwk+jFoIm3B VNctWRtC4iWFqcBdLTpy+H4usucBJJK1hi+IL4KM3aQReZPB7+4pZmoOYWzqgxpbg+E5 19WA== X-Gm-Message-State: AOJu0YycR6AYt14c98CL3mfRTjQ83+XJhA0MUTeBD8nz72lgZ0ETDvQe ghQ7Pi0hG3X3P5j4qmuSyhUmATZjmabzO9fRrztTD9HZjRIa3qLwYSQV8olrex039y8B1RNKARN vTfMS6dZ8o/Nuskdmy28qChIXRXmPjLHRyY1LQGseVm2bmOuy5M+YhimZ83Nr7cD6KAh6RY85s/ tTHIz9DyagpoALcfTVIItf768o1NPHijUs X-Gm-Gg: ASbGncvNQxHQIqkktRwOEleYf2ClNCRouEB6pL42GfzGjrZob+fpH82f9/w6sCHThf1 HsbIi4jJ4huaUHn/gSY8MhKhEoIoiae08TMJ/zWPkGFPmOml3WrGfottor0mGZ/JOIw2v7hlA8q fTmQR2w3gUQwzeKM/0o5aZEjRnol3zHsqBUzTRzUYB/B4jGupk5qT+sIupvUTmQnKVS7HA+ZdnX bqDhABDhHO3a69mDELNslzz5hfzGvfi1GCxeOZiKJEz373PPSnTrhq+Hg1cWrPaWWnH X-Received: by 2002:a05:600c:4e0c:b0:436:e69a:7341 with SMTP id 5b1f17b1804b1-438918b966emr680445e9.3.1737062067370; Thu, 16 Jan 2025 13:14:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IEcGDsPObcnUTGD0WkfMdjVvOmwsn8GvyPXu5ZNzpLopnTrSCPoqhbIcnJif+sMS5dQT9IWqg== X-Received: by 2002:a05:600c:4e0c:b0:436:e69a:7341 with SMTP id 5b1f17b1804b1-438918b966emr680275e9.3.1737062066940; Thu, 16 Jan 2025 13:14:26 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-437c16610a0sm57039775e9.1.2025.01.16.13.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 13:14:25 -0800 (PST) Date: Thu, 16 Jan 2025 22:14:22 +0100 From: Stefano Brivio To: Jon Maloy Subject: Re: [net, v2] tcp: correct handling of extreme memory squeeze Message-ID: <20250116221422.2d977ba5@elisabeth> In-Reply-To: <20250116022918.2225785-1-jmaloy@redhat.com> References: <20250116022918.2225785-1-jmaloy@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Uw2RdLmd8a0WCW6eCO4m0dKQsL3JqxJUwOHdMG0Dybk_1737062068 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ZXIPTOZACXXAAYU7S2D5V4ODFG6CIF5J X-Message-ID-Hash: ZXIPTOZACXXAAYU7S2D5V4ODFG6CIF5J 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, lvivier@redhat.com, dgibson@redhat.com 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 Wed, 15 Jan 2025 21:29:18 -0500 Jon Maloy wrote: > Testing with iperf3 using the "pasta" protocol splicer has revealed > a bug in the way tcp handles window advertising in extreme memory > squeeze situations. The problem occurs on the server side, and > the socket in question is a completely regular socket with the > default settings for the fedora40 kernel. We do not use SO_PEEK > or SO_RCV_BUF on this socket. SO_RCVBUF I think what's missing, at this point, is a short description of the issue. That is (if I recall correctly), under memory pressure, we temporarily advertise a zero-sized window, but this is not stored as part of socket data, the reasoning being that it's a temporary setting which shouldn't influence any further calculation. However, by not storing this information in socket data, we also fail to advertise a non-zero window once we have enough memory to receive data. Our notion of the window size is now different from what we advertised to the peer. The peer won't send any data as a result, but we won't recalculate the window, either, as long as we don't receive any. The rest looks good and very reasonable to me. -- Stefano