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=WjAdcxCy; 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 5F4045A004E for ; Sat, 14 Feb 2026 10:15:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771060546; 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=3iJkYNVu5xQwMz1sBdNKB3hCjSDkqoKYSW694qQx+rw=; b=WjAdcxCydYzb0nXPFzz1uJwn6/XLmFtB2jQnvZyekoWk17JGa7A+HB8/JqpUBC40+W0dmH uETe1bCSJ/xaDUFUvf5CJgl6pXmofiHitEF3LBfxEW7fXkgGjc6feAFc4o0VFT9GHTb53w kYlYEcLpclVSmYRlWCnuQiOt8OeIQ/w= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-204--1ipGX4oOfa2Z-e_7eHwCQ-1; Sat, 14 Feb 2026 04:15:44 -0500 X-MC-Unique: -1ipGX4oOfa2Z-e_7eHwCQ-1 X-Mimecast-MFC-AGG-ID: -1ipGX4oOfa2Z-e_7eHwCQ_1771060543 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4836e35292cso12519915e9.1 for ; Sat, 14 Feb 2026 01:15:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771060543; x=1771665343; 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=3iJkYNVu5xQwMz1sBdNKB3hCjSDkqoKYSW694qQx+rw=; b=umrEh51jznGxi+4dLxFvqxIYesr3h9lc/KK+HbwC+2+xh7+7C00i3ikMs2AJI5kIGc RmtnIWDZs9vueaABk7oO9n9t5fkBSoVFd53ZitxbLqDJuXyMgcrUa9qt42Fhn1gOhibb vRyJioF27Q4Sg2Iu0HDnW8sgZCvCqDi3Uu4eJCVhmNsMWan2IAe80IBWO6caROn4ZQe5 s2pFdWuR5tCmRkPSJOG+eRMpZB8oc88I3g94VtLTxnRxuL5xoLnhlQta0eMMhx/Esy4x zm2wwspufk08fLZv+PSzFfDaPk9tGEyu9snxWEHQQHvNA+w4F610/6bYvPVehFUOXzbj vs8A== X-Gm-Message-State: AOJu0Yy//TwdFrcJptsbV1i7sPU8H4WZFYGzToeATt04QhmibHaQrCJp ih8yql9lE74Cr7cA/BsB8JVNl1ITgOW87uRfxCrZnL6CRfpf8US23F2Gez+1dYSDS9vw523Jtmw tZeExJKW1CHfEVyj3t7AP5ExG+CE2jWUyEf+fuRu+qAvWpsFljjMWBA== X-Gm-Gg: AZuq6aKeqhHFE6DARsKS05xbk4WNzMK9zpcAsp+3gFh0rbGow9vU6D1QCjZ14Bfuh0p kZO+dXt3q7Esk8RmqtWuMKSoJU63UaM3b3DuvszoLYVaKoxBe8tJjOr4DjcxAe4jqxaja4lhnbF vRnpLOAm9n7Zq26wIcLX5gvQXNYZ/6VeOuAxLh8lotLRD6Pz/8P/4wo9pKzobTtVNn15OrKIns5 dbZGaWQR+ELlb1R0pZwWu6NTL6oa5JS7hraSHFg6Ds8Zsban3IIUHKL8VkBU12kWZs+f6EkPRCL JKjNoc0yOlHNLShAKWelhoAyp1EW0Hr7FW+aWPHG6/6I1lYwxEDxWsOLQH3CBJ0TR6R3TeErUYj OHFTk1KoOx2rSsfLkiXeCt4gPnjL6GOjP X-Received: by 2002:a05:600c:1986:b0:483:71f9:37ef with SMTP id 5b1f17b1804b1-483739ff8f5mr84339865e9.8.1771060543041; Sat, 14 Feb 2026 01:15:43 -0800 (PST) X-Received: by 2002:a05:600c:1986:b0:483:71f9:37ef with SMTP id 5b1f17b1804b1-483739ff8f5mr84339395e9.8.1771060542570; Sat, 14 Feb 2026 01:15:42 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4836aa0847asm226049145e9.3.2026.02.14.01.15.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Feb 2026 01:15:42 -0800 (PST) From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] udp: Split activity timeouts for UDP flows Message-ID: <20260214101540.51335a48@elisabeth> In-Reply-To: References: <20260212080414.61889-1-yuhuang@redhat.com> <20260212225136.2734cfc9@elisabeth> <20260213080843.5186d859@elisabeth> <20260213101255.1600250b@elisabeth> <20260213110000.7796ccc3@elisabeth> <20260213111701.0bfec3a7@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: Sat, 14 Feb 2026 10:15:41 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ikMxcAcHSB-5CbQGT51Ej8R4vFOpDycFInNo3zE8rIo_1771060543 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2IOJJZMR27GFEREQUCOTW57LBM2EFOSM X-Message-ID-Hash: 2IOJJZMR27GFEREQUCOTW57LBM2EFOSM 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 Sat, 14 Feb 2026 15:20:26 +0800 Yumei Huang wrote: > On Fri, Feb 13, 2026 at 6:17=E2=80=AFPM Stefano Brivio wrote: > > > > On Fri, 13 Feb 2026 18:04:59 +0800 > > Yumei Huang wrote: > > =20 > > > On Fri, Feb 13, 2026 at 6:00=E2=80=AFPM Stefano Brivio wrote: =20 > > > > > > > > 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 > > > > > > > > > > > > On Fri, 13 Feb 2026 15:49:41 +0800 > > > > > > Yumei Huang wrote: > > > > > > =20 > > > > > > > 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. =20 > > > > > > > > > > > > Ah, right! See below. > > > > > > =20 > > > > > > > Tried either spliced / > > > > > > > non-spliced, pasta / passt case, no exceptions observed. I w= as wondering > > > > > > > if there is a scenario I'm not aware of. =20 > > > > > > > > > > > > Yes, I think it's just for one corner case David described in t= he "Flow > > > > > > sockets" section of the "Theory of Operation" documentation in = udp.c: =20 >=20 > [...] > > 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=3D9725e79888374a4e4060a2d798= f3407c0006cc8a, > 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. --=20 Stefano