On Sat, 14 Feb 2026 15:20:26 +0800
Yumei Huang
On Fri, Feb 13, 2026 at 6:17 PM Stefano Brivio
wrote: On Fri, 13 Feb 2026 18:04:59 +0800 Yumei Huang
wrote: On Fri, Feb 13, 2026 at 6:00 PM Stefano Brivio
wrote: On Fri, 13 Feb 2026 17:54:56 +0800 Yumei Huang
wrote: On Fri, Feb 13, 2026 at 5:13 PM Stefano Brivio
wrote: On Fri, 13 Feb 2026 15:49:41 +0800 Yumei Huang
wrote: > 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:
[...]
Just have another look, instead of this case, I feel it's more like the one described in https://passt.top/passt/commit/udp_flow.c?id=9725e79888374a4e4060a2d798f3407..., which is packets arriving between bind() and connect(), and udp_sock_fwd() / udp_flow_from_sock() is called again to forward the packets. In this case, we should count the activity. The timestamp might not be so accurate, but should be very close. So I'm keeping it.
Hmm, I guess you're right, and actually that path shouldn't be called for listening sockets. In any case, if you update the packet count whenever the timestamp is updated, as you did on v3, that should be correct. Running tests there in a bit. -- Stefano