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=JTeOZgjX; 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 7F1975A0278 for ; Mon, 01 Sep 2025 22:07:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1756757271; 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=/QeTLtX6RcX5/Xbt4t4hi8QYFnGJpPjGuU/9noF20NQ=; b=JTeOZgjXXjp3+ITOS82tBI8M/txW3ElKWmwUn25RQVo+98CitIdQJ8jCuUiQqLDkXnYrgs nGrWsmJr/TNdJlFNJ07KADGQqee5ZsGQ03cfHh1dK1GOEMiRM7O2gziF2WwFVtA5GXw3Tx PfrXrkobaJKzvknkS27axdkTgiYgGr0= 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-496-adenYTm2MZOF6j1C9bKsTw-1; Mon, 01 Sep 2025 16:07:50 -0400 X-MC-Unique: adenYTm2MZOF6j1C9bKsTw-1 X-Mimecast-MFC-AGG-ID: adenYTm2MZOF6j1C9bKsTw_1756757269 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-45b7d485153so34954775e9.0 for ; Mon, 01 Sep 2025 13:07:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756757269; x=1757362069; 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=/QeTLtX6RcX5/Xbt4t4hi8QYFnGJpPjGuU/9noF20NQ=; b=ijz4eI6yWUBUsJIcyf0t3Teyn5oF6MgiTN5nwccqJByJ8YUq0Do6W2pHVI0mHA2S66 XZUdWZ1dqDc/b//TAvm/fkLtEOk5jKzZ6PW8lmWEYn9EOPTrfgo7ppQJ19+r+ygAKu0P XHwy9E7mlZFpGvDI100QATzcLUVjZgYpGNHkqWLmIk/CnFb7Xjud6uncppmbRr276tlq b+m8b44VkH237bx1s7qX9kp/dC/QkXxQwt+ZtrK1nH0TdfPA1w6OJjDW4wnhMmiV/FLl 0AB20CX1pDIqZJtH3krbGoccFTsVDCgo17/9LcGDqRX1rmAblI8wIZgHfkaGZ8ZVr41M xWrw== X-Gm-Message-State: AOJu0YxYsZhP5mnBucVKRDVTmvRGDeKx53a7gS0MPKwTTr1Ox/K3ij/C oGsUJTXMk2Bftgl+Ybv5qH0JcrorL1SvUJ0ba0M++vrAbIXWPX9O8JKXm/f8+khOGDqbUhsZ3gS YztFGhP6Jary/l0+uJJr3EunBElVn/J3kUZXgsQfYpH8dSBbTTUssjA== X-Gm-Gg: ASbGncuaTmn44oqBuyIQBuauzgzoX+VI6spMGMauy53GJw57DntgLJvS8tUe6f1MWCm 6IAUWbgk8nU29+OIDv5dV0Zc4dgn5INjdSBdx+3GT4pZrUE34wnRSYChW0aOog0ryR7g5Zn8z7N 9vhU9CAGigzq2dOX8qFE6WnPEVs959xDLQEOgihJX9JfjbfXHlkpTOGAqauICpcDh7zLKlR1lOG 4vRKsRgCmYP8Nx1GL2AqdjcaKZZxh5z8FtbGCM6ZPB0S0hVDKsgzbyV3lq1+cKO3qtUC4KcXn0+ fOMPAMQDQOq3FSi9PiPklCu2ArGq1AeFcEee70bzkmSgtxSl0MO2w1f114z4HZJtbRgU X-Received: by 2002:adf:a3da:0:b0:3d2:2989:224 with SMTP id ffacd0b85a97d-3d229892c7dmr4594335f8f.7.1756757268806; Mon, 01 Sep 2025 13:07:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF14OerM4+8WyuojJ0boMzXKZLTFHRuUZItTGZmYqbzAhd8COz/wpA0hIrmiSM4AQ552HmTfw== X-Received: by 2002:adf:a3da:0:b0:3d2:2989:224 with SMTP id ffacd0b85a97d-3d229892c7dmr4594323f8f.7.1756757268182; Mon, 01 Sep 2025 13:07:48 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3d6376546c6sm6952030f8f.60.2025.09.01.13.07.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Sep 2025 13:07:47 -0700 (PDT) Date: Mon, 1 Sep 2025 22:07:46 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 3/7] tcp: Rewind sequence when guest shrinks window to zero Message-ID: <20250901220746.1b63e515@elisabeth> In-Reply-To: References: <20250829201132.1561650-1-sbrivio@redhat.com> <20250829201132.1561650-4-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: pDBywyQ71w9OP87SMFC5EOOjOnLhKmcHQuBCQ704BiU_1756757269 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: JUH24OL3WH2N4CVLMKNVCM5NAXMZ7Q7Z X-Message-ID-Hash: JUH24OL3WH2N4CVLMKNVCM5NAXMZ7Q7Z 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, 1 Sep 2025 14:28:33 +1000 David Gibson wrote: > On Fri, Aug 29, 2025 at 10:11:28PM +0200, Stefano Brivio wrote: > > A window shrunk to zero means by definition that anything else that > > might be in flight is now out of window. Restart from the currently > > acknowledged sequence. > > > > We need to do that both in tcp_tap_window_update(), where we already > > check for zero-window updates, as well as in tcp_data_from_tap(), > > because we might get one of those updates in a batch of packets that > > also contains a non-zero window update. > > > > Suggested-by: Jon Maloy > > Signed-off-by: Stefano Brivio > > Reviewed-by: David Gibson > > > --- > > tcp.c | 34 +++++++++++++++++++++++++--------- > > 1 file changed, 25 insertions(+), 9 deletions(-) > > > > diff --git a/tcp.c b/tcp.c > > index 1402ca2..11c9c84 100644 > > --- a/tcp.c > > +++ b/tcp.c > > @@ -1257,19 +1257,25 @@ static void tcp_get_tap_ws(struct tcp_tap_conn *conn, > > > > /** > > * tcp_tap_window_update() - Process an updated window from tap side > > + * @c: Execution context > > * @conn: Connection pointer > > * @wnd: Window value, host order, unscaled > > */ > > -static void tcp_tap_window_update(struct tcp_tap_conn *conn, unsigned wnd) > > +static void tcp_tap_window_update(const struct ctx *c, > > + struct tcp_tap_conn *conn, unsigned wnd) > > { > > wnd = MIN(MAX_WINDOW, wnd << conn->ws_from_tap); > > > > /* Work-around for bug introduced in peer kernel code, commit > > - * e2142825c120 ("net: tcp: send zero-window ACK when no memory"). > > - * We don't update if window shrank to zero. > > + * e2142825c120 ("net: tcp: send zero-window ACK when no memory"): don't > > + * update the window if it shrank to zero, so that we'll eventually > > + * retry to send data, but rewind the sequence as that obviously implies > > + * that no data beyond the updated window will ever be acknowledged. > > Nit: Arguably "no data...will ever" is not quite right. It presumbly > won't be acknowledged until we resend it at least once, but we > certainly hope it will be acknowledged after that point. Hmm, yes, it's "ever" in a rather relative sense (we'll time out, eventually, but that takes a while), which makes it not "ever", strictly speaking. Let me just drop "ever", unless you have better ideas on how to improve the comment. -- Stefano