Re: [PATCH] udp: Split activity timeouts for UDP flows

[Yumei Huang <yuhuang@redhat.com>]

On Fri, Feb 13, 2026 at 6:00 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Fri, 13 Feb 2026 17:54:56 +0800
> Yumei Huang <yuhuang@redhat.com> wrote:
>
> > On Fri, Feb 13, 2026 at 5:13 PM Stefano Brivio <sbrivio@redhat.com> 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 <yuhuang@redhat.com> wrote:
> > >
> > > > On Fri, Feb 13, 2026 at 3:08 PM Stefano Brivio <sbrivio@redhat.com> wrote:
> > > >
> > > > > On Fri, 13 Feb 2026 14:45:24 +0800
> > > > > Yumei Huang <yuhuang@redhat.com> wrote:
> > > > >
> > > > > > On Fri, Feb 13, 2026 at 5:51 AM Stefano Brivio <sbrivio@redhat.com>
> > > > > 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 responses, not
> > > > > > > inbound traffic or passt in vhost-user mode. Then I realised
> > > > > > > that:
> > > > > > >
> > > > > > > On Thu, 12 Feb 2026 16:04:14 +0800
> > > > > > > Yumei Huang <yuhuang@redhat.com> 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 = now->tv_sec;
> > > > > > > > +             udp_flow_activity(uflow, !tosidx.sidei);
> > > > > > >
> > > > > > > ...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, loopback
> > > > > > >    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
> > > > > udp_flow_from_tap(),
> > > > > > >    for consistency, because that's also where we update the timestamp
> > > > > > >    value:
> > > > > > >
> > > > > > >         sidx = flow_lookup_sa(c, IPPROTO_UDP, pif, s_in, dst, port);
> > > > > > >         if ((uflow = udp_at_sidx(sidx))) {
> > > > > > >                 uflow->ts = 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 like the if
> > > > > > condition always returns false.
> > > > >
> > > > > Hmm, weird, it should return false only for the first *inbound* 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 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.
> > > > >
> > > > > 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.
> > > >
> > > > 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 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 socket, 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 connect()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
>


-- 
Thanks,

Yumei Huang