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=KNNcx2dE; 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 E1DB65A0265 for ; Fri, 13 Feb 2026 11:05:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770977120; 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=EdwjsvaR1CYiILFwF2EOh/sigLe1oHAcwCdQkQOK8lA=; b=KNNcx2dEpM1BvxS01SaQaQen5osg7VshP5cr0h5F3gDByzf7TWZuHfqrMNi8Tef6xM6FVh xdqZ6qxKPf9DIhGYIhNJYU3WrB6nPJKGtLTmUdpg/e/iuJ5lUNtjHCeD8Z4j6tT/9YmZ6Z s4veicTihJkbgSKu08By8xqinlsj4DA= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-664-o6JZagy1NSKUyxuWeZnnDQ-1; Fri, 13 Feb 2026 05:05:12 -0500 X-MC-Unique: o6JZagy1NSKUyxuWeZnnDQ-1 X-Mimecast-MFC-AGG-ID: o6JZagy1NSKUyxuWeZnnDQ_1770977112 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-b7fe37056e1so62087766b.2 for ; Fri, 13 Feb 2026 02:05:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770977111; x=1771581911; 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=EdwjsvaR1CYiILFwF2EOh/sigLe1oHAcwCdQkQOK8lA=; b=A5Kp6ph1xuz4/TLHKfwmXFW2VESY6VC2wM082rmd3e/jKLNniEQvYdem75QFB/nVM5 E+mnPQ/cp34g9TXvTy/mgXwQth3N5in3ikYd7iAIeqrYwStdlB7LjErWg2JxAQzK6jKt XhtJG58WAkWMP7maZCst7l7lf7nAHwIuuaKCazE+ZxD+Fcw3qipXHV+/qswTlFOQf+q9 BGlKhMofW26y/ALORzomGwcwEqa2hqcK1sBigNEQkZEtB8SPSH7Z5goQQKkBrureA8YO XOEnRVg8531B5GOu9lm6IWngHqtluVg299JmnywiH3NktdgsH2aTONaq90vvNcaZeOBB JniA== X-Gm-Message-State: AOJu0Yzv7NgcOxClfSAiT6fdrWemmmVhcgO55C0DECDpTNZGqkUJaC8h IZFYSBszWaZhg9+1a7IvD4mUnaAk7t1UH3CK/Vl7kjWC9rBi4ivLvt9/gpYC5VoxZ6b/jevzMR/ r78Zt9Z8phBSre3sqzIhLSFQuPZMvxyUhXWonVTFUMMjRT8rOEIhNSCb9CG9KSgx4kowV2sc46n dxRYBzd3eC0j6vbo+mM+HfXJA68cmp X-Gm-Gg: AZuq6aLGh3m0mSHfNEWuoTYeEGrZuhDjLeRv8CvoQUunYqoLpbnz+xBCq/oidRSfEUx m4wLnwemA50EMc6T7ZR8hBzawlICtdTGSVwUp5howMS2LeZHabRrKUU+eZpeZSOcGu6o8N67V8/ y8ii2Dh2PsIgLrGkXXhd8Tv9EP8tEIH99JXpFq7qSkUGj3zjjfb9Mkh2JJtJ0jw0qDbcCq8ziys xZJ5cA1FwhWsIQj6Vf82yYvvwjC5l95IHY2q5pl45yNurv/82oTrsuxzyeOY+4hYQ1ZFVL0zTQV 1oJfo0IAYy2oOtCLyqKY0g0U X-Received: by 2002:a17:907:720f:b0:b87:2b61:b036 with SMTP id a640c23a62f3a-b8fb4222e78mr69499866b.18.1770977111422; Fri, 13 Feb 2026 02:05:11 -0800 (PST) X-Received: by 2002:a17:907:720f:b0:b87:2b61:b036 with SMTP id a640c23a62f3a-b8fb4222e78mr69498166b.18.1770977110920; Fri, 13 Feb 2026 02:05:10 -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> In-Reply-To: <20260213110000.7796ccc3@elisabeth> From: Yumei Huang Date: Fri, 13 Feb 2026 18:04:59 +0800 X-Gm-Features: AZwV_QjhYMheXW7nyWAyxgXYZ4z_BqpF1Vl6zOX_ntbazXHxVyIb5IXgwaRxbfk 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: CDhqhGY8GsSX62A3xNQ4jc3uKmwJD6C9J623aVr45B4_1770977112 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: HUZEZH7AYCKTWX5UXGPDYCOQ2KAN5H3C X-Message-ID-Hash: HUZEZH7AYCKTWX5UXGPDYCOQ2KAN5H3C 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: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 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= quick > > > > > > > test. > > > > > > > > > > > > > > I just tried outbound DNS queries in pasta with single respon= ses, 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 soc= ket"); > > > > > > > > uflow->ts =3D now->tv_sec; > > > > > > > > + udp_flow_activity(uflow, !tosidx.sidei); > > > > > > > > > > > > > > ...this only covers three of the four paths we need to act up= on: > > > > > > > > > > > > > > 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 = 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 from he= re 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 c= ases, 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 t= imestamp > > > > > > > value: > > > > > > > > > > > > > > sidx =3D flow_lookup_sa(c, IPPROTO_UDP, pif, s_in, ds= t, 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 fair= ly easy > > > > > > > with socat and a UDP "server" inside pasta or a guest. > > > > > > > > > > > > Somehow, it worked well in my tests with pasta, it looks like t= he if > > > > > > condition always returns false. > > > > > > > > > > Hmm, weird, it should return false only for the first *inbound* d= atagram > > > > > 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 mentione= d. > > > > > > > > > > > > Besides, I also noticed we update the timestamp value in > > > > > > udp_flow_from_sock() as well. I feel we should call udp_flow_ac= tivity() > > > > > > 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 gues= s. > > > > > > > > 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() alwa= ys > > > > 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 won= dering > > > > if there is a scenario I'm not aware of. > > > > > > Yes, I think it's just for one corner case David described in the "Fl= ow > > > sockets" section of the "Theory of Operation" documentation in udp.c: > > > > > > * NOTE: A flow socket can have a bound address overlapping with a li= stening > > > * socket. That will happen naturally for flows initiated from a soc= ket, 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 conn= ect()ed > > > * socket in preference to a listening socket. The sample program > > > * doc/platform-requirements/reuseaddr-priority.c documents and tests= that > > > * 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. > > 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. > > -- > Stefano > --=20 Thanks, Yumei Huang