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=QQXoGDxM; 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 5E8D95A0271 for ; Wed, 24 Sep 2025 11:56:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758707801; 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=YVxehCFxMbj312wfoQgl70tszZphy43B+fs5oQQAUxo=; b=QQXoGDxMhQugau3/20B09mALgO77vxSwmFOJbidVVkOq4ckh/LCzFABPCofzIVExADx0Lk CmFtkegGTehmXfNNaBfj6p4qgxJzgKIOs32oocU7eOVmG1AQs15GA+CTLAhh/SewDhZ1Zn K+ThOVbH8VoG4AOcqkLEx1OTClxZeFU= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-PG5a6lUMMmerkk4Xa1SenA-1; Wed, 24 Sep 2025 05:56:39 -0400 X-MC-Unique: PG5a6lUMMmerkk4Xa1SenA-1 X-Mimecast-MFC-AGG-ID: PG5a6lUMMmerkk4Xa1SenA_1758707798 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-3ed9557f976so5520443f8f.3 for ; Wed, 24 Sep 2025 02:56:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758707798; x=1759312598; 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=YVxehCFxMbj312wfoQgl70tszZphy43B+fs5oQQAUxo=; b=BCq2Egg75zvKgqj2v/9YgKmrJgjwafC0Sh7xIkSwCBodQrkCaCJytf/DNEnasViTUX H6+x+OLJy/AE2Vej9wIiU6bhU5U307NWIRstUHufDElp+YVqlYPqK67bUK9/bSfyTEwh G4QCdIfQcwS96LDP9IItWNNHG90WVeo9PSOcKXzv7icZoIyCxYDcwuUNvXU8kvVH/Ya/ KUqNvsInWg/eHW2cFbta+vIcBSj28heP3Ak0xbkLHvq0K9pTN6uJ/yeYeUHg/1s4kHMF IBYZ05YRohSCgWeWJSlDt1eX6ZtqkBED4akn+tVRBnR0gKizCm+MP+nSZTymA9/jOpNF l+3A== X-Forwarded-Encrypted: i=1; AJvYcCWUQ7TWwZ3dv4YNS6NTZIPzozKNcOPQQkDNC/ND9sIZf57LwD5r/M01eV1kHW2HCiSjYb0G1KOlWro=@passt.top X-Gm-Message-State: AOJu0Yx/7rbUOLRRaesiqkUaCctBLHITYaa8Q7DMM/C1oJ1LVOmaOko9 bxFw0luNPqzSpnODtKlwpq7M/sg51OLAXwr8J6JUwjz79zUzGAM60XQfg8GiXcmLBsRVm06xN17 UNrajtHm1Di6lI6XgdZ/RSHsbiGHl/ygZrIoyv4DP3aMRDYAm1Uj1JQ== X-Gm-Gg: ASbGnctMFTkp31AUBNf0mnsddsAYLoATTyHKtITl4m+jr/IKi5B6uo6B8NOY/00qCyh KxG99IQ+gTlUL0vhn7/sxBhbujSy1+Zj02YcLZXJWcgU/Mr6L8GaFfee6w+CRCdBPDInx/lfaN6 G1NnL7F13wZ7EBtAUtNSBZE2yZuLW1W9go4OF80yT/dNvlJCIKZK0clW5lN4FKZE693Sr9PtfyT NHrbzanPigB4uYz/CPkH42OJPxcIJ2R9f2ry7gYeC6XVt+OR901wsALR9A9zcpgAfvgAOdEW08y eHD6/QrIDn9brGM9jqNX4BPySG9i5sKhGCchKhkhOkQxBAt5xJYQLl+Jg/cjwej7DKHM X-Received: by 2002:a05:6000:2c10:b0:3ec:dfe5:17d0 with SMTP id ffacd0b85a97d-405c5bd81c4mr4740042f8f.9.1758707798178; Wed, 24 Sep 2025 02:56:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF9ar9fUe4MFOSu9DgtfZLFJDykOGLBrAedD1TOT6Eah0jPj/ddZ/751pE+V/Tm+ujV+GY5MA== X-Received: by 2002:a05:6000:2c10:b0:3ec:dfe5:17d0 with SMTP id ffacd0b85a97d-405c5bd81c4mr4739959f8f.9.1758707795671; Wed, 24 Sep 2025 02:56:35 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3fee58e6e25sm10828870f8f.58.2025.09.24.02.56.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Sep 2025 02:56:35 -0700 (PDT) Date: Wed, 24 Sep 2025 11:56:33 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] tap: Drop frames if no client connected Message-ID: <20250924115633.01368e9a@elisabeth> In-Reply-To: References: <20250915081319.00e72e53@elisabeth> <20250918091714.77192b00@elisabeth> <20250922220330.436e2b6f@elisabeth> <20250923130039.41e8ef8d@elisabeth> <20250924015609.58c1987a@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: QzxDEM2DWw5yEH_VVGAwtnbTwcnQy-y9smeoK_6kZd8_1758707798 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FRLE5XPONEMIDPN4IAFUVGU2HUIGMMIB X-Message-ID-Hash: FRLE5XPONEMIDPN4IAFUVGU2HUIGMMIB 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, lvivier@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, 24 Sep 2025 11:49:28 +1000 David Gibson wrote: > So... summarising. As I see it, we have two main cases to consider: > the one where the guest comes online pretty soon, and the one where it > doesn't. Here's what I think the behaviour would be for these two > cases with a variety of ways of handling it. This is more-or-less > from the peer's perspective. > > (0) Physicaly disconnected guest (bridged network, no passt involved) > > (0a) Guest online never > SYN ... SYN ... SYN ... > > (0b) Guest online soonish > SYN ... SYN ... SYN-ACK, ACK > > (1) Status quo > > Passt doesn't resend SYNs, and will time out the connection after 10s. > > (1a) Guest online never > SYN, SYN-ACK, ACK ... ... ... ... RST > > (0b) Guest online soonish > SYN, SYN-ACK, ACK ... ... ... ... RST > > (2) Yumei's patch > > As (1), but without EBADFs > > (3) passt resends SYNs > > (3a) Guest online never > SYN, SYN-ACK, ACK ... ... ... ... ... RST > > (3b) Guest online soonish > SYN, SYN-ACK, ACK ... ... ... ... > > (4) Passt resends SYNs + Yumei's patch > > As (3), but without EBADFs > > (5) passt explicitly resets when guest is not present > > (6a) Guest online never > SYN, SYN-ACK, ACK, RST > > (6b) Guest online soonish > SYN, SYN-ACK, ACK, RST > > (6) Delayed listen() > > (6a) Guest online never > SYN, RST > > (6b) Guest online soonish > SYN, RST > > (99) Bridged guest isn't listening (no passt) > > (99a) Guest online never > SYN, RST > > (99b) Guest online soonish > SYN, RST > > ===== It all makes sense, thanks for summarising those. > So, if (99) is our model, we can match it pretty exactly with delayed > listen(). But if (0) is our model, the closest we can get is (3) or > (4), which I think will look fairly similar to peer application, even > though it looks different to the peer TCP stack. > > I think (0) is a better model, because it means we won't reset > connections if they happen to land when a still running guest has its > connection to passt temporarily interrupted. > > Which brings me, I think, to the same conclusion you had: we should > resend SYNs. > > Suggested next steps: > - Apply Yumei's patch, it doesn't change behaviour and removes the > odd EBADFs > - Yumei investigates implementing SYN resends Right, that also makes sense to me. For the second part, we could probably reuse a mechanism similar to what we do for re-transmits, and perhaps rename 'retrans' in struct tcp_tap_conn to 'retries', so that we can use it for both (we're a bit tight on space there). -- Stefano