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=ayQcvD5r; 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 B64F05A026F for ; Thu, 25 Sep 2025 07:08:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758776931; 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=PGMFbRLVgDgAtxJb26782I9N1dDHwDACnrwiMqCzYOo=; b=ayQcvD5reFvr0VnGKFl6JDCRfmt7sTiuRWhjD2/GzD7pufuF1Wb5mEJwuPay11G5QC94dQ cEFqDek+UePwlAALCH+I21lpdQjmuiHjobAWtkhgUjADJW5PY71peYDVk4KJz8wfRqM6GV XZ/0NunArfa6213cYNXVEjk/sHTGx8A= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-665--X0hZDKSMfGxqzuMy6jzoQ-1; Thu, 25 Sep 2025 01:08:48 -0400 X-MC-Unique: -X0hZDKSMfGxqzuMy6jzoQ-1 X-Mimecast-MFC-AGG-ID: -X0hZDKSMfGxqzuMy6jzoQ_1758776927 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-b311b7aa78fso48683866b.3 for ; Wed, 24 Sep 2025 22:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758776926; x=1759381726; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PGMFbRLVgDgAtxJb26782I9N1dDHwDACnrwiMqCzYOo=; b=APg+bTJ9E8mudVkWPX3LvIA9XkXO5LtNYI0VDmr/ncDLXVBfcZ3WlkqU9xXutLwpLJ lb9sfrdxDAkc2Bz32w/v7au/Vbr6t0Om5O396uE1AdCAMf7VTWp3GIyZ//hHib3JBc45 K4wGPov9vrjhupe+An2V0enBXaHMy43JGy55lOUa1BneYpAIBkTQ/v8jdtalytAlr+yQ 7cfQgsdXoIjOg5EPlqP4fhfM8hlLgKEbw1apC9Ec4aGnkEUmittpK6BXLxIBd35U9HR8 pWtuOIVh+Q5wlacxAaXXMY7g5SsawhgdVLx1jP3BDrsSRFWGscTFI5kAOLAtEavoANU1 5CtQ== X-Forwarded-Encrypted: i=1; AJvYcCWH4uDv5tDS1pc9tQVkNcxIRJwV8ZU7wVQIS9t7LJA+os8dYdXppKyb/8lu/NAJ8IZJ99jJXTyQMVQ=@passt.top X-Gm-Message-State: AOJu0Yw05Vhg1EDdlX+wtgz4l9PlAx1vOY06EVVaOZvf2XRauCQ/VrBO WvBGaeml8RmThPdRxW8FNGhFCRXjNRqBDHbGpUqwnpDWlIOkCVFmysk/sLkdWoTNef9laVtDMST Geh4TDkdcvi5EK5J3zWIgFFUJLMJ7rhUuhPQMDs18zVmF7EYc2FLMwN7zvItQo4v3MvVH/mqEuy HOonDobHdTiTp71bAs4qGBl8zrER14NNQfTqca7mc= X-Gm-Gg: ASbGncuM8EvttMdRcFUPXAmp+XTMGU5XdXuc5moVheFBu3SSorL42+CL9XTE6yF8OSY wbB/p8kaW5+iTzvO/8AOqhdme0HLPBbcbliAhvAS2SLXHYFgZQkNKIxQ7Ja7Xc5/doh1UAGDcAm zMMlc5wSvGfdEWFK18n84KHg== X-Received: by 2002:a17:907:97d3:b0:b07:da17:79fd with SMTP id a640c23a62f3a-b34b9e59f5bmr208877366b.17.1758776926566; Wed, 24 Sep 2025 22:08:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFEv7U/UeeUz8VOS7U0Wd3UvTfFQJnP0NSZKD1Rq42Fr1n24eQzSxNxVqepJ311OU7HE7M24WmOVhKo39K7OBI= X-Received: by 2002:a17:907:97d3:b0:b07:da17:79fd with SMTP id a640c23a62f3a-b34b9e59f5bmr208875466b.17.1758776926190; Wed, 24 Sep 2025 22:08:46 -0700 (PDT) MIME-Version: 1.0 References: <20250915081319.00e72e53@elisabeth> <20250918091714.77192b00@elisabeth> <20250922220330.436e2b6f@elisabeth> <20250923130039.41e8ef8d@elisabeth> <20250924015609.58c1987a@elisabeth> <20250924115633.01368e9a@elisabeth> In-Reply-To: <20250924115633.01368e9a@elisabeth> From: Yumei Huang Date: Thu, 25 Sep 2025 13:08:35 +0800 X-Gm-Features: AS18NWBBaLGpg1rI7RINOvqVqwv_rkAVx6k05x8AWflQ_bIPVTeOurw65MxKNuA Message-ID: Subject: Re: [PATCH] tap: Drop frames if no client connected To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: aIofT54HCN3v-ga8nZCvWOOwSdEtwYHrzpIwrrwXgqM_1758776927 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: LU3N6FI2WLURSUGAEBP2BOLXWI5MJWDV X-Message-ID-Hash: LU3N6FI2WLURSUGAEBP2BOLXWI5MJWDV X-MailFrom: yuhuang@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: David Gibson , 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, Sep 24, 2025 at 5:56=E2=80=AFPM Stefano Brivio = wrote: > > 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 > > > > =3D=3D=3D=3D=3D > > 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. Glad we reached an agreement here. BTW, in case you missed it, the v2 patch was sent as https://archives.passt.top/passt-dev/20250912081705.20796-1-yuhuang@redhat.= com/T/#u. > > 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). I got an initial thought about calling tcp_send_flag() in tcp_flow_defer(). But it seems not working. Trying to figure that out.. > > -- > Stefano > --=20 Thanks, Yumei Huang