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=XtLipply; 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 749795A004E for ; Sat, 14 Feb 2026 08:20:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771053641; 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=3nk5TEungaUROSI8qATnM9muAp1+j9ZIn9eMnG6MILw=; b=XtLipplyPnGznijB2L6XaJPPWR+vWnCE3V9KAOM5Ix86n33aVdLQ1sNO0sH60qLpE8myfK ZMozDfvbOaIQUgLFOVA9lW0JQqpzehjZ1/LTD+nXPpF+ayw1sNeT57pnfqFwzeIhYoz44M NsK6fYPUFBJeMR+LTvIUCsRd7gGf5BU= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-dsGnLhs9PyyGen2Rv2ncGg-1; Sat, 14 Feb 2026 02:20:39 -0500 X-MC-Unique: dsGnLhs9PyyGen2Rv2ncGg-1 X-Mimecast-MFC-AGG-ID: dsGnLhs9PyyGen2Rv2ncGg_1771053638 Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-6581a45f30eso1303230a12.2 for ; Fri, 13 Feb 2026 23:20:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771053638; x=1771658438; 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=3nk5TEungaUROSI8qATnM9muAp1+j9ZIn9eMnG6MILw=; b=Vw6QfYdxNxTMqqryV3+pkntYYxMmpPy3OuGjC2FALlePS6khR0FM2KIvidVdd4S+iH /GF/ofGlKzdfoqFDIWacBhy53AZKArPo2leXRwSUuP0j9MjrnxnXCsv1PfnhQo7uiuD1 fA9156Z7ZygSO1L2a5ctwFpvtMVhNSsesBJYDJSfVj2J9+X86nSZB6u6xktxcaCZmV/L TYlVIkteNZq4MWSbgZE7JbNvQ9rtSj3Pbp7wylxwJfoCvv+/k170TejYwTit9yEdEO7D KRZYWJ/4GvGALG2PwFOnD4Yp/clzLPxh06grEjI8E2ulBLGlhHGJ2aSWmMqOtxE3foSR Hfuw== X-Gm-Message-State: AOJu0YzIKgSLqocY0lv3qEJ82HalapgF73e+xNzaJ4XIOQw8NaMenlia 3/7igUr4HwXhGVp/PrelQgKf6zcD8h/PWBehmuRNt3sxteohyEA8rkLwmHvOXo39T2pVkMyRtxl AUMnC7e1d/yNo+ruBvxgPdpQFq8YUU9dPU1Byt7MzyHtV5F3DXutsRFpvgzdSa9VImPbr89IdGI mqYy2a147+IRwS/mcWbw0+kTtksD+i X-Gm-Gg: AZuq6aK6mRGM6LxR4nwYxlBQs3rOvOus6eh5IRqjf+bR+tQNVdaGuV/jmpRFAGk7a68 VvVHBwiuzGGOjo4KFSGPqmM7D4L9By5+PoiWnGFLGs0Z6APWqpJfajNbfA6Zj/x8431YWBB73QZ XHksJe/2IxLn9748cMTqfBA3fajBzAGE0WhbLDbMC+PP9VaDkoYclwNzd+IVVyftU+IQMLBelkJ fVDadYK32pJjur4xqHuvp2lOlqwxkUa0BUELxQvtb0K2dlayTwCZO8yBBV+4AC5aN4BvjWIf/xG /G1AkJRU7kbYFNLL6DfNfzvG X-Received: by 2002:a05:6402:278b:b0:65a:409c:6fe6 with SMTP id 4fb4d7f45d1cf-65bb1161199mr2340678a12.15.1771053637879; Fri, 13 Feb 2026 23:20:37 -0800 (PST) X-Received: by 2002:a05:6402:278b:b0:65a:409c:6fe6 with SMTP id 4fb4d7f45d1cf-65bb1161199mr2340670a12.15.1771053637263; Fri, 13 Feb 2026 23:20:37 -0800 (PST) MIME-Version: 1.0 References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@elisabeth> <20260213101255.1600250b@elisabeth> <20260213110000.7796ccc3@elisabeth> <20260213111701.0bfec3a7@elisabeth> In-Reply-To: <20260213111701.0bfec3a7@elisabeth> From: Yumei Huang Date: Sat, 14 Feb 2026 15:20:26 +0800 X-Gm-Features: AaiRm501vfusgvOX7wlx8YyJ-NbEmZIthZPnSmdbZ9xbuiz0mUWWOLs73oUPmuI 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: VOU5PyxfO3YKDP15V0bf-CMwW_3sfX84WV4VQZvyjj8_1771053638 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: EGDSMTXL6L5CQ5SGDVIN2WGEFAOS77UW X-Message-ID-Hash: EGDSMTXL6L5CQ5SGDVIN2WGEFAOS77UW 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 6:17=E2=80=AFPM Stefano Brivio = wrote: > > On Fri, 13 Feb 2026 18:04:59 +0800 > Yumei Huang wrote: > > > On Fri, Feb 13, 2026 at 6:00=E2=80=AFPM Stefano Brivio wrote: > > > > > > On Fri, 13 Feb 2026 17:54:56 +0800 > > > Yumei Huang wrote: > > > > > > > On Fri, Feb 13, 2026 at 5:13=E2=80=AFPM Stefano Brivio wrote: > > > > > > > > > > [Side note: can you disable sending HTML emails, otherwise they w= on't > > > > > be archived for the passt-dev list for simplicity / security? Tha= nks] > > > > > > > > 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 duri= ng a quick > > > > > > > > > test. > > > > > > > > > > > > > > > > > > I just tried outbound DNS queries in pasta with single re= sponses, not > > > > > > > > > inbound traffic or passt in vhost-user mode. Then I reali= sed > > > > > > > > > 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 ac= t 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 pass= t's vhost-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, loopback > > > > > > > > > UDP traffic, handled by udp_sock_to_sock(), called fro= m here as well > > > > > > > > > > > > > > > > > > but not: > > > > > > > > > > > > > > > > > > 4. outbound, non-spliced datagrams from container/guest: = that's > > > > > > > > > udp_tap_handler(), in both vhost-user and non-vhost-us= er 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 t= he timestamp > > > > > > > > > value: > > > > > > > > > > > > > > > > > > sidx =3D flow_lookup_sa(c, IPPROTO_UDP, pif, s_in= , dst, port); > > > > > > > > > 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 easy > > > > > > > > > with socat and a UDP "server" inside pasta or a guest. > > > > > > > > > > > > > > > > Somehow, it worked well in my tests with pasta, it looks li= ke the if > > > > > > > > condition always returns false. > > > > > > > > > > > > > > Hmm, weird, it should return false only for the first *inboun= d* datagram > > > > > > > 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 ment= ioned. > > > > > > > > > > > > > > > > Besides, I also noticed we update the timestamp value in > > > > > > > > udp_flow_from_sock() as well. I feel we should call udp_flo= w_activity() > > > > > > > > there too, but couldn't come up with a test to prove it. > > > > > > > > > > > > > > I haven't really checked, but udp_sock_handler() should anywa= y 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 data > > > > > > 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= wondering > > > > > > 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 ud= p.c: Just have another look, instead of this case, I feel it's more like the one described in https://passt.top/passt/commit/udp_flow.c?id=3D9725e79888374a4e4060a2d798f3= 407c0006cc8a, which is packets arriving between bind() and connect(), and udp_sock_fwd() / udp_flow_from_sock() is called again to forward the packets. In this case, we should count the activity. The timestamp might not be so accurate, but should be very close. So I'm keeping it. > > > > > > > > > > * NOTE: A flow socket can have a bound address overlapping with = a listening > > > > > * socket. That will happen naturally for flows initiated from a= socket, but is > > > > > * also possible (though unlikely) for tap initiated flows, depen= ding 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 progra= m > > > > > * doc/platform-requirements/reuseaddr-priority.c documents and t= ests that > > > > > * assumption. > > > > > > > > > > ...if they don't come through the connect()ed socket, we would en= d up > > > > > in that case. > > > > > > > > > > Long story short, we need to update the activity array there as w= ell, > > > > > 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 re= ally > > > > > needed though. > > > > > > > > Thanks, I will add that and send v2 soon. > > > > > > Actually, if we always want to update the 'activity' array when we > > > update the timestamp, maybe you could add a helper that does both, > > > update 'ts' and 'activity'. > > > > > > It could still be called ...activity() because the timestamp is also = an > > > activity timestamp. > > > > Good idea. Guess I sent v2 too soon. > > > > > > I haven't checked all the possible paths though, I'm not sure if it's > > > the right thing to do. > > > > I will check tmr. If no other changes are needed, I will sent v3 then. > > Okay, thanks! > > -- > Stefano > --=20 Thanks, Yumei Huang