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=cqnJ2Xco; 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 B866B5A0265 for ; Fri, 13 Feb 2026 10:13:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770973983; 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=3zvXFR3td15swTPq6ByUQI/610zZBMicivX3J6KPezs=; b=cqnJ2XcobZMsCjb9U3iJyXGhlb/ZCM6GZxu02BXFr7+zz/8U1BREqUnejCHm5uTvwlaDg+ 9GSR2m9miEe/+h4CZNPi1hiYxctYTguLaWpt8ow03ZFRlBeyW4tIrdcFDPV5plsTCN42Hf Fc5ch4oaCK3ImHmy8twz3MEH9z3595s= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-691-n1IZjT8AN2ijz1iYbaJF-A-1; Fri, 13 Feb 2026 04:13:01 -0500 X-MC-Unique: n1IZjT8AN2ijz1iYbaJF-A-1 X-Mimecast-MFC-AGG-ID: n1IZjT8AN2ijz1iYbaJF-A_1770973980 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-43623cfb160so513070f8f.1 for ; Fri, 13 Feb 2026 01:13:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770973980; x=1771578780; 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=KBEFm5h+Jee5GybG1kEjFwsf6E2jLI8mTjU4dgf3whY=; b=c4Y+IxUTO6ZD3zEHIDD2oA2ja7yGzy/vJOgUM6Le41XLqR2rHLDeycnTS+LzhD0u0d xFi7lsc3SkjlMPFO/7Fh3mQOxmX0cpNSTW9ENqawbxwcbROl1OIamDa3DLyrSxKDqTsV rPY12y9NcVhI5BCVLrBEjUjUdNCc+C4y4Dj7VEv0jyJ9vvBBnm/qFQJ6dC10K6ce/2mq HwLcsFna1bsyDnfhpWSSHor+JwZzYa9UYHocw9DAQP+rgnwE7euQBSKo8RVOwls/sgZw t9sG6i8kTAGKN8EyB+sXwDjqeqY8AZzp13i+DcHmfFRVRZjHHTufIR6oJwmA/AQ5Pm0N Wa4w== X-Gm-Message-State: AOJu0YyjOw/fay4hHOCvvnK2bTV6dkwWqN2pSO+RMZRDtF0W0CSSERqR QXeghMnSV2OlEOgt0EDTEicdXR3jrwpl0/chwWPh6DoziQB5I+Et9yVVjwuZ5QO1tD6aVHVaroI +0sGPg6t9wOZYWpsIcpc1NJspGLDqH+0kHOEnIGrElsQMo4DR5HjL/Q== X-Gm-Gg: AZuq6aIk7bwWuT9pSZe0WR9f//EYSZPIEmeDPyRefLAymg/zJ39X9hWPOkF+honKFCj 19x48Ey7xV+Ejl2OihTECqwL7HlVQivjaAgD0dCmIHfGTLkYXPZ2o+WwgK1LRdNu3d+0xWvz+pL gR3ah0URCs0w53piRfutoqtPEPO/1f6oDmjDs5DuTfh22I3SHCK5z4bBD7DpBinjrV7DMmddpLt THXr5WdWGXLsSkQb4tnjWyEVH5ofoR2EcyGOxorVFzTR0qkN/E46XYZgjU1HuIOJNFUpvTWjVxD 3peQqUxhoFNoWyTFXJS2s3RD9TRvRcumj6zEK4DVFoDb0bZTkBaMID342RgXJM8CVMIFNRIVJto BA/8NOPYM7nVw5FCh/Li24L6SRdfVWvXQ X-Received: by 2002:a05:6000:208a:b0:436:3475:473f with SMTP id ffacd0b85a97d-43797918575mr1961193f8f.36.1770973980269; Fri, 13 Feb 2026 01:13:00 -0800 (PST) X-Received: by 2002:a05:6000:208a:b0:436:3475:473f with SMTP id ffacd0b85a97d-43797918575mr1961127f8f.36.1770973979603; Fri, 13 Feb 2026 01:12:59 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796abc8b1sm4162615f8f.23.2026.02.13.01.12.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 01:12:58 -0800 (PST) From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] udp: Split activity timeouts for UDP flows Message-ID: <20260213101255.1600250b@elisabeth> In-Reply-To: References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@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 10:12:58 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ZbrzIzMbTXppwhwrYLBOVwFmfVMVOl6OJsdsoNGHQwg_1770973980 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: IYPUJVRLWZUBCU4ESOQIGQYY5IDDFIVD X-Message-ID-Hash: IYPUJVRLWZUBCU4ESOQIGQYY5IDDFIVD 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: [Side note: can you disable sending HTML emails, otherwise they won't be archived for the passt-dev list for simplicity / security? Thanks] 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: >=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 responses, n= ot > > > > 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 socket"); > > > > > 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, we can't = call > > > > splice(), but a pair of recvmmsg() / sendmmsg()), that is, loopb= ack > > > > 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 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 timesta= mp > > > > value: > > > > > > > > sidx =3D flow_lookup_sa(c, IPPROTO_UDP, pif, s_in, dst, por= t); > > > > 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 eas= y > > > > 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* datagra= m > > 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_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 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 >=20 > 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...? > 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 udp.c: * NOTE: A flow socket can have a bound address overlapping with a listenin= g * socket. That will happen naturally for flows initiated from a socket, b= ut is * also possible (though unlikely) for tap initiated flows, depending on th= e * source port. We assume datagrams for the flow will come to a connect()e= d * 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. > > > 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. =20 > > > > Same here, I *thought* that calling udp_flow_activity() from > > udp_sock_handler() *and* udp_tap_handler() would anyway account for the > > first datagram, but I didn't check. >=20 > 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. --=20 Stefano