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=Rc98/UUN; 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 7D6E65A0619 for ; Wed, 29 Oct 2025 05:53:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761713585; 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=OlxYQBBhRIGgr0VLb19/BzWYblSp8W15/4oMzwtrrN8=; b=Rc98/UUNM21hQ8CUg9iQyfxZnSf7Pda43TRKhPBA7lQjR4+tNjKBdxUl0tw5aIe6ICHUHZ VuhTTZvhrMs8cf2p3XnVlAFC+yqt86F6nFI29oWkgAOoVnLq8x425o2GVlOLj/rNctrq3U 7IiQGVuhUY10q9fWjX6DZJaLAjDPjsw= 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-589-XhmvKDz3Pc6XHokkDCno_w-1; Wed, 29 Oct 2025 00:53:03 -0400 X-MC-Unique: XhmvKDz3Pc6XHokkDCno_w-1 X-Mimecast-MFC-AGG-ID: XhmvKDz3Pc6XHokkDCno_w_1761713582 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-47111dc7c5dso2676095e9.0 for ; Tue, 28 Oct 2025 21:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761713582; x=1762318382; 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=OlxYQBBhRIGgr0VLb19/BzWYblSp8W15/4oMzwtrrN8=; b=U5hPymGzPzWE/NutsRaYGBd6SivfQXQnEUEsllZcJPsJNf/k8ZRwTqOQNuiXbvvW8n 5u/oe3MM90D/4Tjzr5kNVTbRmY1QeM7iXl9gnsm4h9rgkWIYonBbt0qn8M3Buqzubng1 UF70LHi8BjJMZ5lS6CEKzQJKQx4QRstDHmIsrJll5EMb/XZLpeOjEoeWaz4OK4CExt+t Rm3J34Ct4W/LkphH9sk6Z4M6PmEn4GaNHky2GkGBPzI0+FzEyn0ZJ9qVFlZGo4V3m27F Nv5J1T3aP0PpJsaHdM7/gA6xWSAThyqeMsETlnmLaj3LpGLyqdCNVXNlKGXXceXohYMS XWEg== X-Forwarded-Encrypted: i=1; AJvYcCXWcVeVJeaLD2qRLC2GxA9GnSmr6O87unJGOxt900QAedZL0uBpfZs6SzQuil4Dl7P97qMxvRob2pY=@passt.top X-Gm-Message-State: AOJu0YxOyKN7y2pXqP/yB0Oc06CM13qpYLtS7iVBFjw6NRGvngpNq36C xpEVMpudjfcBAACVeSu+OanB+sK9lpJZkAo4hX4JZkCmtMwbsAxEi6xeirTdNLJO6KvwNN3bZpE nF29UIp9epLhEsMiExJVa5c/1jpTGL2fGiJnN3Wfw5fVgWmqwicQSxQ== X-Gm-Gg: ASbGnctLCC9m2DcK+NNwJmdxTNCSJbpfUuBPzyVLpyfRKCpFPFUuH2MN7zbwJQ3uZZo h6dsqmWQ7isxpQaO7CMQT1CSfkYL7vhzuu1azNOKq7hwR5NShcTvwlYB7Hd1wOAUjPWWPGkrKVc rg4RpAN3TpJkzTUVNy3iBiNaUVddfFhuANeCXGFla4g2fyI9wicUydOjxPJ2rmBv1ecZD5g1V9d iirwuEAgwD3fW5jdxurxLpirw4I+w4wFPo9CS1rJxqex0w8obBW+oSJOK+d4YkpJSj6QHCLIc3t oSUh7UzhDtjA1D1v7qPPHbcq/CllneHZoHy8qg12Od3HpT0j9trm8sqJjjzaMVqf+83OXVHhyK8 eX2rnl5xT3A== X-Received: by 2002:a05:600c:4f0b:b0:476:8ce0:a737 with SMTP id 5b1f17b1804b1-4771e68ac36mr11515115e9.14.1761713582322; Tue, 28 Oct 2025 21:53:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEU5shqYbA1x3x3ndo7FcTCon846akrhxX1HaycxqENFMB3MfTBIHsNFVXQYQSNUB+WtP/A4w== X-Received: by 2002:a05:600c:4f0b:b0:476:8ce0:a737 with SMTP id 5b1f17b1804b1-4771e68ac36mr11514995e9.14.1761713581858; Tue, 28 Oct 2025 21:53:01 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4771e387aa9sm25818905e9.4.2025.10.28.21.53.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Oct 2025 21:53:01 -0700 (PDT) Date: Wed, 29 Oct 2025 05:52:59 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 4/4] tcp: Update data retransmission timeout Message-ID: <20251029055259.2ad35fde@elisabeth> In-Reply-To: References: <20251014073836.18150-1-yuhuang@redhat.com> <20251014073836.18150-5-yuhuang@redhat.com> <20251017202812.173e9352@elisabeth> <20251020071107.42fd40e9@elisabeth> <20251029001330.579cc85a@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: 9bGcRWoElcGBg6eH_UTgvtiPe9X5s4pQ47_bOB-EBE4_1761713582 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 3WVKFIMVRFSGHSMDOTIFSE65OBNMTBI2 X-Message-ID-Hash: 3WVKFIMVRFSGHSMDOTIFSE65OBNMTBI2 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: Yumei Huang , passt-dev@passt.top 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, 29 Oct 2025 11:35:29 +1100 David Gibson wrote: > On Wed, Oct 29, 2025 at 12:13:30AM +0100, Stefano Brivio wrote: > > On Mon, 20 Oct 2025 20:17:10 +1100 > > David Gibson wrote: > > > > > On Mon, Oct 20, 2025 at 07:11:07AM +0200, Stefano Brivio wrote: > > > > On Mon, 20 Oct 2025 11:20:19 +1100 > > > > David Gibson wrote: > [snip] > > > > > > Rather than the local link I was thinking of whatever monitor or > > > > > > liveness probe in KubeVirt which might have a 60-second period, or some > > > > > > firewall agent, or how long it typically takes for guests to stop and > > > > > > resume again in KubeVirt. > > > > > > > > > > Right, I hadn't considered those. Although.. do those actually re-use > > > > > a single connection? I would have guessed they use a new connection > > > > > each time, making the timeouts here irrelevant. > > > > > > > > It depends on the definition of "each time", because we don't time out > > > > host-side connections immediately. > > > > > > Hm, ok. Is your concern that getting a negative answer from the probe > > > will take too long? > > > > More like getting a positive answer taking too long, because we retry > > so infrequently. > > Right, but it will only be slow if we lose the first probe, which > should be very rare. No, because again, that might be due to the guest doing something with its firewall or stopping/resuming/getting online etc. It's not necessarily rare. If that situation persists for at least 1 + 2 + 4 + 8 + 16 + 32 = 55 seconds, without a clamp, we'll wait 119 seconds next, and 247 seconds after that. In this case, to me, it looks more reasonable to retry every minute instead. > > > > Pretending passt isn't there, the timeout would come from the default > > > > values for TCP connections. It looks like there's no specific > > > > SO_SNDTIMEO value set for those probes, and you can't configure the > > > > timeout, at least according to: > > > > > > > > https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-tcp-liveness-probe > > > > > > My guess would be that the probe would probably time out at the > > > application level long before the TCP layer times out, but I don't > > > know for sure. > > > > I don't think so. What I was pointing out is that I couldn't find any > > place in the implementation of those probes where a particular > > *handshake timeout* (not probe interval) is set on top of Linux's > > defaults, so timeouts at TCP layer and application level should be the > > same (no additional timeout in application logic). > > Huh, that's mildly surprising to me. -- Stefano