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=cpd6ujoX; 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 4298A5A0279 for ; Thu, 11 Sep 2025 02:12:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1757549537; 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=cRNRVv07LsUTV6FUAhSR06PftUGe9IdesdUFCfR6ysM=; b=cpd6ujoXvtIrLlJjlJu0kqpiA6KTq26KsFePNTuk4YQE68TlJdFasAQ3NfkXuDupfhBBmQ MAPx8J4oUgfnzoF8rz+7xai6gbXrzrYjILGefh4/ttng4vGlg9GGEot79N2mNh8/LdkEYs UEFtQouyc5+ENtP2WaGKwxABkkS8njw= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-677-7ZamvLgfMJK4G3pmXH1xnQ-1; Wed, 10 Sep 2025 20:12:15 -0400 X-MC-Unique: 7ZamvLgfMJK4G3pmXH1xnQ-1 X-Mimecast-MFC-AGG-ID: 7ZamvLgfMJK4G3pmXH1xnQ_1757549535 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-81b8d38504fso44855385a.3 for ; Wed, 10 Sep 2025 17:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757549535; x=1758154335; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cRNRVv07LsUTV6FUAhSR06PftUGe9IdesdUFCfR6ysM=; b=DNH8S59DmCkCVr8rdUPYGYsIZSVt34uOLmtIuEe8Yb69p8kC8x7MwUlgGAYrODTTyd 2tH5QrN398/m0Kz/ZEkTJeuBFu747GP2wdJX9oDE3ascLfYZg3RltZTU8DXcEbmbDgnO 3vDbhzK7rBW9TgrDK91S8Go+IM8iVJMYb9UHmgsimWMioEDsejPaqZOzBvaHJvGlv913 sAMfXCEj1knEhtD/P9V9TjQlj8OmUymLFgXucDx4cHtDr2/HfsUAcrffF5pKyDxbS5uP WsZuzXRylMI7InTThkGgQ+WEp4KetTpItoq9h4/xmysex3GxwX/hLtyZlfyNx7QsJW9y c3Vg== X-Forwarded-Encrypted: i=1; AJvYcCXWmuXC7w4ilmKU+uyvau3v4YDCw1zrFPeVk6DKvxwhD9y7Kx9HyGPpW53VgQZGCuBZ0W632Us1WfE=@passt.top X-Gm-Message-State: AOJu0Ywa2tBbDd+l0uwdWIUY3+mi/mjUW32Wixf1SMYjpIUGnEq2ZVsL LVR/EAaJeyJ15S+6VGUi7LZMmMxR43pOjV4/nmmZ+SIipNbtaPaHPZ2q3ZaTWrjUXkI5g1y6s+S 45tG0SQu0EJzzEHsugVN2EwlBpiUPaGEvOBDJtpjKt6vo8Hz6Ysj5xA== X-Gm-Gg: ASbGnct6VybI/ZDLvoX3Qz+LSqnxshy4OTRjuyDGZ3QSXf7l06S2Ptqf2A2DsbX5XGQ kOV4UfgXFe66tGga1LYiKCdwhsJuGfwKE5esGu5z0pwO+Sw8xo6X4b254cg1Ibtf/x8Y77qFYSb pX2wOvoNRY02G5aJzOaSUOkOwiu0m1G2RxA2ykDO8y8FfrKqVuh+US2kmXHLCLtxwbCi9tt3pjD 7/zgfTAtoH5G+0Iz0TXBSgwnXfYQHq5V0Krz+OC/72yr35WvYEYCB1MyPND5/8TFZnZxzvoaJLq pk9kZ+9Q+aP+miwZ3Dd12H5Go5rfvch/tCVAkbQedS5Ep6biDv1ZdNc/0zvFaIIF0u9vAcMNq5F OQ6cFQhGTPg== X-Received: by 2002:a05:620a:4556:b0:81d:7e0c:3202 with SMTP id af79cd13be357-81d7e0c33e5mr707963285a.49.1757549534967; Wed, 10 Sep 2025 17:12:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG/7blP030jlmPZp3NpTa0FJ+6xa/UUXq72SScSkMk4FxHQeY9Ath6dxRZBuSvsNxawmpagYA== X-Received: by 2002:a05:620a:4556:b0:81d:7e0c:3202 with SMTP id af79cd13be357-81d7e0c33e5mr707959785a.49.1757549534402; Wed, 10 Sep 2025 17:12:14 -0700 (PDT) Received: from ?IPV6:2001:4958:2206:8901:6025:1483:4146:72dd? ([2001:4958:2206:8901:6025:1483:4146:72dd]) by smtp.gmail.com with ESMTPSA id af79cd13be357-820ce94abc5sm5825085a.54.2025.09.10.17.12.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Sep 2025 17:12:13 -0700 (PDT) Message-ID: <2aa49410-9bf9-40d0-bfcf-c88c80c0430a@redhat.com> Date: Wed, 10 Sep 2025 20:12:13 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 5/8] tcp: Don't try to transmit right after the peer shrank the window to zero To: Stefano Brivio , passt-dev@passt.top References: <20250909181655.2990223-1-sbrivio@redhat.com> <20250909181655.2990223-6-sbrivio@redhat.com> From: Jon Maloy In-Reply-To: <20250909181655.2990223-6-sbrivio@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3cdBlt4ih_c6wP7wVJBhbaPXZ1EExyDF7lP4mvvfd6s_1757549535 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 3IQFJJJFDDR5CU3PUG72BXVUEH72AOJY X-Message-ID-Hash: 3IQFJJJFDDR5CU3PUG72BXVUEH72AOJY X-MailFrom: jmaloy@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: Paul Holzinger , David Gibson 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 2025-09-09 14:16, Stefano Brivio wrote: > If the peer shrinks the window to zero, we'll skip storing the new > window, as a convenient Is this really convenient? It looks more like an inconsistency with potential for future trouble to me. Wouldn't it be better with just a SEND_WIN_PROBE flag or similar to be reset as soon as the window goes non-zero again? > way to cause window probes (which exceed any > zero-sized window, strictly speaking) if we don't get window updates > in a while. > > As we do so, though, we need to ensure we don't try to queue more data > from the socket right after we process this window update, as the > entire point of a zero-window advertisement is to keep us from sending > more data. > > Signed-off-by: Stefano Brivio > Reviewed-by: David Gibson > --- > tcp.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/tcp.c b/tcp.c > index b83510b..9c70a25 100644 > --- a/tcp.c > +++ b/tcp.c > @@ -1271,8 +1271,10 @@ static void tcp_get_tap_ws(struct tcp_tap_conn *conn, > * @c: Execution context > * @conn: Connection pointer > * @wnd: Window value, host order, unscaled > + * > + * Return: false on zero window (not stored to wnd_from_tap), true otherwise > */ > -static void tcp_tap_window_update(const struct ctx *c, > +static bool tcp_tap_window_update(const struct ctx *c, > struct tcp_tap_conn *conn, unsigned wnd) > { > wnd = MIN(MAX_WINDOW, wnd << conn->ws_from_tap); > @@ -1285,13 +1287,14 @@ static void tcp_tap_window_update(const struct ctx *c, > */ > if (!wnd && SEQ_LT(conn->seq_ack_from_tap, conn->seq_to_tap)) { > tcp_rewind_seq(c, conn); > - return; > + return false; > } > > conn->wnd_from_tap = MIN(wnd >> conn->ws_from_tap, USHRT_MAX); > > /* FIXME: reflect the tap-side receiver's window back to the sock-side > * sender by adjusting SO_RCVBUF? */ Not so sure. That sender will stop in due time anyway, with no harm done. Starting fiddling with SO_RCVBUF sounds like something to avoid. > + return true; > } > > /** > @@ -2101,9 +2104,8 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af, > if (!th->ack) > goto reset; > > - tcp_tap_window_update(c, conn, ntohs(th->window)); > - > - tcp_data_from_sock(c, conn); > + if (tcp_tap_window_update(c, conn, ntohs(th->window))) > + tcp_data_from_sock(c, conn); > > if (p->count - idx == 1) > return 1; > @@ -2113,8 +2115,8 @@ int tcp_tap_handler(const struct ctx *c, uint8_t pif, sa_family_t af, > if (conn->events & TAP_FIN_RCVD) { > tcp_sock_consume(conn, ntohl(th->ack_seq)); > tcp_update_seqack_from_tap(c, conn, ntohl(th->ack_seq)); > - tcp_tap_window_update(c, conn, ntohs(th->window)); > - tcp_data_from_sock(c, conn); > + if (tcp_tap_window_update(c, conn, ntohs(th->window))) > + tcp_data_from_sock(c, conn); > > if (conn->seq_ack_from_tap == conn->seq_to_tap) { > if (th->ack && conn->events & TAP_FIN_SENT)