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=G4AdYwz+; 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 BADB05A0265 for ; Fri, 13 Feb 2026 11:17:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770977827; 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=Svj19Fuz3LwfGiRUW7hcUO8bswDVrnqXzOa9PGmjhuY=; b=G4AdYwz+P8n2lsevOya8ko5DvHyz7dvpkQaTOhRZxzaE90iixO6r16HVZBDt+tvJYFcHgw VYa4BANZNR2WjWltY0DeI6JuPeoyfoEwrbPg3s47iUq4WGskAs1D0D3v1vxydI8fCGuZd3 OEGHh7j7RN5mN6FTyXH2AgCEc5sFHJg= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-212-aT5cZKiNPhWPoMrZH1IGZQ-1; Fri, 13 Feb 2026 05:17:06 -0500 X-MC-Unique: aT5cZKiNPhWPoMrZH1IGZQ-1 X-Mimecast-MFC-AGG-ID: aT5cZKiNPhWPoMrZH1IGZQ_1770977825 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43591aacca2so765924f8f.1 for ; Fri, 13 Feb 2026 02:17:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770977825; x=1771582625; 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=vbuDuR1Imrf2wuLsh8kBr7/8kjuTkfBsKgmoDi+xdNY=; b=sR3ObtumtsobghzUd49Uf/9YitAzOwF2wnu36hrzuCdek1AVFKW5voRzcHPV6vDPcw cdR3j75mHFze1fnV0Lm3lEm17/NQLxtbjzPTMWGLaMzZ7/fGAkIwAJxLT9a/tY+geTda 4NZWcIT4Mi3TGjIWLNAJ+bOCH4oO+Fobm5PCKji6qk8miNIoF+RH/wvroobie/bRZBEv irgBBd5u8BXvg9+eyYCs4lQe+WrKurcjKrKncsP5Cml7H7LJwPbmI7GQ+5mb22PMe/xA P1jewV3pKfMUMnB83GMhv94BbG+kEfVA++UnFCGkiw2+f4Z7REbGLZmcAkiG/iDI/ff8 Wsag== X-Gm-Message-State: AOJu0Yw7MG9kQSgwQHvNlfaO0Dd1aLfztuRtec3AtU+o5AvC8nHy2thH mBlX5vwFxgCAwcvBRXYLhv+Th83zr7EsxHHFcLSdHKo5MyFwiDq9B49NSiBSKgIJNUEg46OfD6u 28jndiMrMMssDZ/etcJm+mpqSHTe49P5Cuf/bX4qOAVAKqdiui6oYMw== X-Gm-Gg: AZuq6aJwrrvWhbgIhVfZr4xwOyx7w3reE3zn2+KWJY/AnZ6ER22A5G/8w+3PzQt6vHT 8Kncby45OzFhCr9oSTNWMO+UyYo5hvbhHZhRkV3vHW4LcFrnWzjOGPG9klCLngBsmSOB9TbydpI CHr2rJk0qVLaKCZpVCQB9ww0/ofO62BVQPjHts7qK7k+slGrya6E84vmiCsqaQ8Y3uUtwurpMwS +0SkA/8yU+dM8ynlXyp5wVhVYPNpSia5FUvgipNw/Ps3xOIGxItvE+Aayp5YF2EmnGCz0T3TOy+ QmzvR1l3af8Q9SReMAZNNGTm0e2MxBlNJcDW+zRPnSE+/XxMDdBykKn4c+QuLW5XkAJUDOjgY7X 7eXlHVonynHmWvic/2guJqldykILjsYmD X-Received: by 2002:a05:6000:186f:b0:434:2569:275d with SMTP id ffacd0b85a97d-437978eae64mr2399727f8f.26.1770977824669; Fri, 13 Feb 2026 02:17:04 -0800 (PST) X-Received: by 2002:a05:6000:186f:b0:434:2569:275d with SMTP id ffacd0b85a97d-437978eae64mr2399672f8f.26.1770977824143; Fri, 13 Feb 2026 02:17:04 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796a5d156sm4896235f8f.5.2026.02.13.02.17.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 02:17:03 -0800 (PST) From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] udp: Split activity timeouts for UDP flows Message-ID: <20260213111701.0bfec3a7@elisabeth> In-Reply-To: References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@elisabeth> <20260213101255.1600250b@elisabeth> <20260213110000.7796ccc3@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:17:03 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: pTjNK1oc2e6faV1CF_SGoH9vlh3X2RXCw9lEcGkyUBc_1770977825 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: YNHLZTIPVP3LPGOU7LBAVKAYXB4LBUV2 X-Message-ID-Hash: YNHLZTIPVP3LPGOU7LBAVKAYXB4LBUV2 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 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: > > =20 > > > On Fri, Feb 13, 2026 at 5:13=E2=80=AFPM Stefano Brivio wrote: =20 > > > > > > > > [Side note: can you disable sending HTML emails, otherwise they won= 't > > > > be archived for the passt-dev list for simplicity / security? Thank= s] =20 > > > > > > Yeah, sorry about that, will keep in mind to enable the plain text mo= de. =20 > > > > > > > > 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 quick > > > > > > > > test. > > > > > > > > > > > > > > > > I just tried outbound DNS queries in pasta with single resp= onses, not > > > > > > > > inbound traffic or passt in vhost-user mode. Then I realise= d > > > > > > > > that: > > > > > > > > > > > > > > > > On Thu, 12 Feb 2026 16:04:14 +0800 > > > > > > > > Yumei Huang wrote: > > > > > > > > =20 > > > > > > > > > [...] > > > > > > > > > @@ -954,6 +964,7 @@ void udp_sock_handler(const struct ct= x *c, =20 > > > > > > union =20 > > > > > > > > epoll_ref ref, =20 > > > > > > > > > > > > > > > > > > flow_trace(uflow, "Received data on reply s= ocket"); > > > > > > > > > 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 vhost-user > > > > > > > > mode, that's udp_vu_sock_recv(), also called from here > > > > > > > > > > > > > > > > 3. "spliced" sockets (that's not really the case for UDP, w= e can't call > > > > > > > > splice(), but a pair of recvmmsg() / sendmmsg()), that i= s, loopback > > > > > > > > UDP traffic, handled by udp_sock_to_sock(), called from = here as well > > > > > > > > > > > > > > > > but not: > > > > > > > > > > > > > > > > 4. outbound, non-spliced datagrams from container/guest: th= at'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 =20 > > > > > > udp_flow_from_tap(), =20 > > > > > > > > for consistency, because that's also where we update the= 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 fa= irly 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*= datagram > > > > > > 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 mentio= ned. > > > > > > > > > > > > > > Besides, I also noticed we update the timestamp value in > > > > > > > udp_flow_from_sock() as well. I feel we should call udp_flow_= activity() > > > > > > > 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 d= on't > > > > > > think you need an extra call to udp_flow_activity() there. > > > > > > > > > > > > But you should check that with a pair of debugging prints, I gu= ess. =20 > > > > > > > > > > Actually I did. udp_sock_handler() is called everytime there is n= ew data > > > > > from the socket. =20 > > > > > > > > Okay, so the udp_flow_activity() you already added (at least for th= e > > > > socket -> tap path) is enough, right...? =20 > > > > > > Yes, it's enough for the socket->tap path. =20 > > > > =20 > > > > > But in my test, udp_flow_from_sock() is only called for > > > > > the first datagram, so the if condition after flow_lookup_sa() al= ways > > > > > 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 w= ondering > > > > > 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 = listening > > > > * socket. That will happen naturally for flows initiated from a s= ocket, but is > > > > * also possible (though unlikely) for tap initiated flows, dependi= ng on the > > > > * source port. We assume datagrams for the flow will come to a co= nnect()ed > > > > * socket in preference to a listening socket. The sample program > > > > * doc/platform-requirements/reuseaddr-priority.c documents and tes= ts 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 wel= l, > > > > because it could happen. I'm not sure if reuseaddr-priority.c can b= e > > > > used to test this case together with pasta, I don't think it's real= ly > > > > needed though. =20 > > > > > > Thanks, I will add that and send v2 soon. =20 > > > > 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. =20 >=20 > 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. =20 >=20 > I will check tmr. If no other changes are needed, I will sent v3 then. Okay, thanks! --=20 Stefano