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=WH5DeV75; 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 D5AAB5A0265 for ; Fri, 13 Feb 2026 11:00:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770976806; 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=a6Pxj5Dn4/dCqZI3fcrTb+l8CNIBCycAo2oUe6dXYYc=; b=WH5DeV75NG+feJ6GVNAulbW5vlrT5EETKqth2/UFuWReNRl8SjwE0jsdZqDlik1DTkjdVK CQshhPZW1hkB0jZmmFzGm15A3dlX1ig99UqDbHBmehnAiCmbmazjkAxaY1ohjSDt3fG7u4 tlSarZbsQ5UU5rS4VwRKvYL30/KzI7I= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-443-8U9zcVPnPdaqRp4E4hq41w-1; Fri, 13 Feb 2026 05:00:04 -0500 X-MC-Unique: 8U9zcVPnPdaqRp4E4hq41w-1 X-Mimecast-MFC-AGG-ID: 8U9zcVPnPdaqRp4E4hq41w_1770976803 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4806cfffca6so7630555e9.2 for ; Fri, 13 Feb 2026 02:00:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770976803; x=1771581603; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dwzdV5eN9AYOeRbixXOuwb2TaIvwgAUEqXGKLLbDdaw=; b=Q9e99QAAmmjMwUXQyXqXE/0Xh/AzvKUuhko5FWhXsehugXbr1fGjqz0fZCstjinXyr WZ1isnhAyXHtoz3xkoDk+PPkEDoKdwM5mOkvljOKGobCf9jqwd968cbNWzDFQV7M5tiC 3djxIDfVIf9kR7vN9DssW/GBRHYEZ8tsRTdZG2vATZ69rwFOT24UMMLr96+Yut7OfLP2 +BuCoKMwxnyU8GCgN+euKS7P/9xSD6hcJz8uC5Gfjv2RJIcDqYiCOh7vvm5k/JaQaU2t KQGFyjman3zjmE1zUd231bSXqX6D9/hTnqrrk60R/j5Yw6xTn2QmyTRajeIIsJXZj9zp OTpw== X-Gm-Message-State: AOJu0YwP6Z2HBz79zPNs1NDLO7TsFoa1AeMPFlU3RwLfNu+0k5X8y06J s5idzb2+jl2V9ltfj1PtN9ls7lCvQ/PGdJDuQshOdI83dkVx6/XxbRZd4GSoqjVgVQoQV5HJ0Ib VHtG+kcM4NeN1uhG/hu7nt7j+p9QFxoTN+fiBTUCFu6J37G0ywjlA2Q== X-Gm-Gg: AZuq6aIDHUnowWT1oLjZdG97a2Eemij13HzcvvMziQw5OfeKyBWSlp4Yq6lqUwIZywz G7YokdkH2dG1J3/rBtPeAMFkgBB9IIXdSSnHpC9oe7S7fcu6nTnKrB2GfeGpog9VpB96FBFiNKL xRX3Z1h92+vYBDJRLX73quDOByXTatEvqlOPB1tUb5TbTzds/vGlJsrx4RZLewDnFFsapXVOqhl B3osbyUruWhU7/16bvOwrFpn+OhcC4UwMgg7aQIUII2h+zuhVyeB1ifqPag6zVGvks/qOdvyE2I G3eNg/BHRSc159rI6d4MK37UBt3xGbXyhPv7YiX9OFvSomCRZP3rWRAkq6DIM+fRwUZ+ZsIgweM eyJ7u/Y1AfAvNI6TbYhUJAViUJrPcAU6c X-Received: by 2002:a05:600c:8706:b0:483:6fc6:1e20 with SMTP id 5b1f17b1804b1-48373a09effmr17730745e9.9.1770976803132; Fri, 13 Feb 2026 02:00:03 -0800 (PST) X-Received: by 2002:a05:600c:8706:b0:483:6fc6:1e20 with SMTP id 5b1f17b1804b1-48373a09effmr17730165e9.9.1770976802569; Fri, 13 Feb 2026 02:00:02 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4836ff00332sm50810935e9.2.2026.02.13.02.00.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 02:00:01 -0800 (PST) From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] udp: Split activity timeouts for UDP flows Message-ID: <20260213110000.7796ccc3@elisabeth> In-Reply-To: References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@elisabeth> <20260213101255.1600250b@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Fri, 13 Feb 2026 11:00:01 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: KL_S_lxMRpcMwHzQNMjXrFU__X-AipWblrn9VeCpuY8_1770976803 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: YU23ZDJZQVJ4ZKRKU3HM27WXW7ZGKJ6X X-Message-ID-Hash: YU23ZDJZQVJ4ZKRKU3HM27WXW7ZGKJ6X 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: 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, 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 won't > > be archived for the passt-dev list for simplicity / security? Thanks] = =20 >=20 > 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: > > =20 > > > On Fri, Feb 13, 2026 at 3:08=E2=80=AFPM Stefano Brivio wrote: > > > =20 > > > > On Fri, 13 Feb 2026 14:45:24 +0800 > > > > Yumei Huang wrote: > > > > =20 > > > > > On Fri, Feb 13, 2026 at 5:51=E2=80=AFAM Stefano Brivio =20 > > > > wrote: =20 > > > > > =20 > > > > > > Oops, I missed one point at a first review, and also during a q= uick > > > > > > test. > > > > > > > > > > > > I just tried outbound DNS queries in pasta with single response= s, 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: > > > > > > =20 > > > > > > > [...] > > > > > > > @@ -954,6 +964,7 @@ void udp_sock_handler(const struct ctx *c= , =20 > > > > union =20 > > > > > > epoll_ref ref, =20 > > > > > > > > > > > > > > flow_trace(uflow, "Received data on reply socke= t"); > > > > > > > uflow->ts =3D now->tv_sec; > > > > > > > + udp_flow_activity(uflow, !tosidx.sidei); =20 > > > > > > > > > > > > ...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 vh= ost-user > > > > > > mode, that's udp_vu_sock_recv(), also called from here > > > > > > > > > > > > 3. "spliced" sockets (that's not really the case for UDP, we ca= n't call > > > > > > splice(), but a pair of recvmmsg() / sendmmsg()), that is, l= oopback > > > > > > UDP traffic, handled by udp_sock_to_sock(), called from 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-user cas= es, or > > > > > > udp_flow_from_tap() in udp_flow.c. > > > > > > > > > > > > I guess we want to take care of this directly from =20 > > > > udp_flow_from_tap(), =20 > > > > > > for consistency, because that's also where we update the tim= estamp > > > > > > 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. =20 > > > > > > > > > > Somehow, it worked well in my tests with pasta, it looks like the= if > > > > > condition always returns false. =20 > > > > > > > > Hmm, weird, it should return false only for the first *inbound* dat= agram > > > > of a UDP flow. > > > > =20 > > > > > 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_acti= vity() > > > > > there too, but couldn't come up with a test to prove it. =20 > > > > > > > > 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.= =20 > > > > > > Actually I did. udp_sock_handler() is called everytime there is new d= ata > > > from the socket. =20 > > > > Okay, so the udp_flow_activity() you already added (at least for the > > socket -> tap path) is enough, right...? =20 >=20 > Yes, it's enough for the socket->tap path. > > =20 > > > 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. =20 > > > > Ah, right! See below. > > =20 > > > Tried either spliced / > > > non-spliced, pasta / passt case, no exceptions observed. I was wonde= ring > > > if there is a scenario I'm not aware of. =20 > > > > 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 list= ening > > * socket. That will happen naturally for flows initiated from a socke= t, but is > > * also possible (though unlikely) for tap initiated flows, depending o= n the > > * source port. We assume datagrams for the flow will come to a connec= t()ed > > * socket in preference to a listening socket. The sample program > > * doc/platform-requirements/reuseaddr-priority.c documents and tests t= hat > > * 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. =20 >=20 > 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. I haven't checked all the possible paths though, I'm not sure if it's the right thing to do. --=20 Stefano