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=Ck9ExA9w; 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 90FBE5A0265 for ; Fri, 13 Feb 2026 10:55:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770976510; 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=X9Ls6YbnhEQqrDtkgHmMEqOiyCc/JjPL+8CkLynyVk8=; b=Ck9ExA9wIGkIk3viIPEQoFH2tqddgCpsllHSgIc4mlJbdX0CCSf9BQAx4YDbwxHzsUMqzx V9dpJ6OUdJyafS9mDuzHNxi2G+JrhSJGkW+6BeDheMykgHNuIYmX7+vTvTcdRO9/z8E3Nd ol5rYhKq/H4pFnPiA8DqjRTRrmTcO4o= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-36-ZDG2HQd5OKiZKumlBglitA-1; Fri, 13 Feb 2026 04:55:09 -0500 X-MC-Unique: ZDG2HQd5OKiZKumlBglitA-1 X-Mimecast-MFC-AGG-ID: ZDG2HQd5OKiZKumlBglitA_1770976508 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-65b26363923so676792a12.0 for ; Fri, 13 Feb 2026 01:55:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770976508; x=1771581308; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=X9Ls6YbnhEQqrDtkgHmMEqOiyCc/JjPL+8CkLynyVk8=; b=vHeXztMmRQ7jHos1L8pjH5K9c/7kiP5FcyoUIgji4CGKnimfVqUBTbxq2cEWrG9Ug2 8WTzru+1csj7edAxOZ7W/eR38195CoTxNemfavw+MP4Y0UkELnuaa4gefyFvgvxKGOj8 X++mPjXdPwSu45Z2Xz6gWQ6htFtROmpCT9gVuC686EhnqfdPKw5fyLxMxqVS+dZ6oYj0 eunjbBf4ecf79ditZbUueb3dzDeIXimzwUZ2ieXpCMUutw8gqWDAO6DZ0UlPuDIxI/LR sIVYBxoCjPapvELS4948q5wu9aayiXTX9NMkt61AnvECYfEZZXvqJDN8UZR5eTqCsj/f aRXw== X-Gm-Message-State: AOJu0YxGFryLEPL/0F4d2l4JcXvHtfhMYKIKBT5Upd83zQVhNYFVxIm8 x5wDSKSEoOVgekIsWWtVlvo3ccEY66jtk0XAvDmDWjyDJRfdy5qBJnuHN/xvGgGqAC0bNznQVgn ZUBNMorxIhvM31vIpnyDtEb0A9bTbtUJIbxviuMdRQ8MmoggHZMNi6UAigESDw9aE7aGk8y2T2L Bq8TwkjBVbH5Pdeh4siWe5iNvZ24Lo X-Gm-Gg: AZuq6aIuA+TDojayTevu3q2bHGELA+BgVfE6bM3v82b8tRNlz3fxOi9wpDefXDeGUuS qn6ZhkASkzyhF84qvJwPrFmidnbyoZL3mw6q1j8miAaS6sDwf1tD3xWbs+kJUR2EjqM9ibi3bm+ KlNX9FWz7uxCH3es5QuI3NjpnrVWrnsfUFkgO9CWAtsTOXfJjzScZmNIANVGRZB5TBaGrjWuAy2 SsOw51mKvK+pUZydOAMG/7cJTfMfPKwbfW9rHSci+e5fP7PGQmylAB61F99W3A/A+uXFgt3srxy y/L8xPt4CTLeSdeMCpo9MU8C X-Received: by 2002:a17:907:97d6:b0:b76:f090:777b with SMTP id a640c23a62f3a-b8fb421ae1amr57674266b.22.1770976507663; Fri, 13 Feb 2026 01:55:07 -0800 (PST) X-Received: by 2002:a17:907:97d6:b0:b76:f090:777b with SMTP id a640c23a62f3a-b8fb421ae1amr57673166b.22.1770976507131; Fri, 13 Feb 2026 01:55:07 -0800 (PST) MIME-Version: 1.0 References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@elisabeth> <20260213101255.1600250b@elisabeth> In-Reply-To: <20260213101255.1600250b@elisabeth> From: Yumei Huang Date: Fri, 13 Feb 2026 17:54:56 +0800 X-Gm-Features: AZwV_QhLa9eXe7aRh8vvC9CGwy9R6_ZfDdRmcDYTpQ3WFFwG9iJrRxCuccnPBjo Message-ID: Subject: Re: [PATCH] udp: Split activity timeouts for UDP flows To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EJ-4-6sHS5ymSX6QnMlZu7l-BOe4rMNkUdBhked9gzQ_1770976508 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: X3ME4JLTCNVOJKWYYN35RSCYEKZJW2C2 X-Message-ID-Hash: X3ME4JLTCNVOJKWYYN35RSCYEKZJW2C2 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: passt-dev@passt.top, david@gibson.dropbear.id.au 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 Fri, Feb 13, 2026 at 5:13=E2=80=AFPM Stefano Brivio = wrote: > > [Side note: can you disable sending HTML emails, otherwise they won't > be archived for the passt-dev list for simplicity / security? Thanks] Yeah, sorry about that, will keep in mind to enable the plain text mode. > > On Fri, 13 Feb 2026 15:49:41 +0800 > Yumei Huang wrote: > > > On Fri, Feb 13, 2026 at 3:08=E2=80=AFPM Stefano Brivio wrote: > > > > > On Fri, 13 Feb 2026 14:45:24 +0800 > > > Yumei Huang wrote: > > > > > > > On Fri, Feb 13, 2026 at 5:51=E2=80=AFAM Stefano Brivio > > > wrote: > > > > > > > > > Oops, I missed one point at a first review, and also during a qui= ck > > > > > test. > > > > > > > > > > I just tried outbound DNS queries in pasta with single responses,= not > > > > > inbound traffic or passt in vhost-user mode. Then I realised > > > > > that: > > > > > > > > > > On Thu, 12 Feb 2026 16:04:14 +0800 > > > > > Yumei Huang wrote: > > > > > > > > > > > [...] > > > > > > @@ -954,6 +964,7 @@ void udp_sock_handler(const struct ctx *c, > > > union > > > > > epoll_ref ref, > > > > > > > > > > > > flow_trace(uflow, "Received data on reply socket"= ); > > > > > > uflow->ts =3D now->tv_sec; > > > > > > + udp_flow_activity(uflow, !tosidx.sidei); > > > > > > > > > > ...this only covers three of the four paths we need to act upon: > > > > > > > > > > 1. inbound datagrams received on the reply socket via > > > > > udp_buf_sock_to_tap(), called from here > > > > > > > > > > 2. inbound datagrams received on the reply socket in passt's vhos= t-user > > > > > mode, that's udp_vu_sock_recv(), also called from here > > > > > > > > > > 3. "spliced" sockets (that's not really the case for UDP, we can'= t call > > > > > splice(), but a pair of recvmmsg() / sendmmsg()), that is, loo= pback > > > > > UDP traffic, handled by udp_sock_to_sock(), called from here a= s well > > > > > > > > > > but not: > > > > > > > > > > 4. outbound, non-spliced datagrams from container/guest: that's > > > > > udp_tap_handler(), in both vhost-user and non-vhost-user cases= , or > > > > > udp_flow_from_tap() in udp_flow.c. > > > > > > > > > > I guess we want to take care of this directly from > > > udp_flow_from_tap(), > > > > > for consistency, because that's also where we update the times= tamp > > > > > value: > > > > > > > > > > sidx =3D flow_lookup_sa(c, IPPROTO_UDP, pif, s_in, dst, p= ort); > > > > > if ((uflow =3D udp_at_sidx(sidx))) { > > > > > uflow->ts =3D now->tv_sec; > > > > > > > > > > ^^^ here > > > > > > > > > > return flow_sidx_opposite(sidx); > > > > > } > > > > > > > > > > I haven't really tested this side of it but it should be fairly e= asy > > > > > with socat and a UDP "server" inside pasta or a guest. > > > > > > > > Somehow, it worked well in my tests with pasta, it looks like the i= f > > > > condition always returns false. > > > > > > Hmm, weird, it should return false only for the first *inbound* datag= ram > > > of a UDP flow. > > > > > > > But now when I test with passt, it becomes > > > > an issue and we need to track the activity here as you mentioned. > > > > > > > > Besides, I also noticed we update the timestamp value in > > > > udp_flow_from_sock() as well. I feel we should call udp_flow_activi= ty() > > > > there too, but couldn't come up with a test to prove it. > > > > > > I haven't really checked, but udp_sock_handler() should anyway be > > > called for the datagram triggering udp_flow_from_sock(), so I don't > > > think you need an extra call to udp_flow_activity() there. > > > > > > But you should check that with a pair of debugging prints, I guess. > > > > Actually I did. udp_sock_handler() is called everytime there is new dat= a > > from the socket. > > Okay, so the udp_flow_activity() you already added (at least for the > socket -> tap path) is enough, right...? Yes, it's enough for the socket->tap path. > > > But in my test, udp_flow_from_sock() is only called for > > the first datagram, so the if condition after flow_lookup_sa() always > > returns false, and a new UDP flow is created. > > Ah, right! See below. > > > Tried either spliced / > > non-spliced, pasta / passt case, no exceptions observed. I was wonderi= ng > > if there is a scenario I'm not aware of. > > Yes, I think it's just for one corner case David described in the "Flow > sockets" section of the "Theory of Operation" documentation in udp.c: > > * NOTE: A flow socket can have a bound address overlapping with a listen= ing > * socket. That will happen naturally for flows initiated from a socket,= but is > * also possible (though unlikely) for tap initiated flows, depending on = the > * source port. We assume datagrams for the flow will come to a connect(= )ed > * socket in preference to a listening socket. The sample program > * doc/platform-requirements/reuseaddr-priority.c documents and tests tha= t > * assumption. > > ...if they don't come through the connect()ed socket, we would end up > in that case. > > Long story short, we need to update the activity array there as well, > because it could happen. I'm not sure if reuseaddr-priority.c can be > used to test this case together with pasta, I don't think it's really > needed though. Thanks, I will add that and send v2 soon. > > > > > On top of it, I just found two other issues. > > > > 1. in udp_flow_new(), we should initialize uflow->activity[INISIDE= ] to 1 > > > > instead of 0. Otherwise, we fail to track the first datagram. > > > > > > Same here, I *thought* that calling udp_flow_activity() from > > > udp_sock_handler() *and* udp_tap_handler() would anyway account for t= he > > > first datagram, but I didn't check. > > > > udp_sock_handler() is only called *after* the flow is created. But only > > when the first datagram comes, we create the flow. Similarly, > > udp_flow_from_tap() (called by udp_tap_handler()) calls udp_flow_new() = to > > create a new flow for the first datagram too. That's why we missed the > > first one. > > Oh, I see, thanks for the explanation. > > -- > Stefano > --=20 Thanks, Yumei Huang