From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2AE7B46BE1 for ; Tue, 22 Jul 2025 10:31:08 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B6AAE402A5; Tue, 22 Jul 2025 10:31:07 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 2063140265 for ; Tue, 22 Jul 2025 10:31:05 +0200 (CEST) Received: from debian (unknown [78.109.70.163]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id BBEF7E06BE; Tue, 22 Jul 2025 12:31:03 +0400 (+04) DKIM-Filter: OpenDKIM Filter v2.11.0 agw.arknetworks.am BBEF7E06BE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arknetworks.am; s=default; t=1753173064; bh=9tQ2S1JPwZyE3H0HP4vnpoBAKQqYGmblrG40u3YDm/M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lN96T8Cs38gfHkUu0W6L/xVqItxnT138YPA+IgDxUYtlBhSBrnDvl104T1kNqRRMz qa4b3ihTBPZbYEPYKh7P5bq0PhGHONTu+kX7ZGIblXN/4N3ZAdnArnpKGunSU4o6Zf ErGhkt4cG3qNmIIizKnLTH0iVzDPnZO2iTG4HS/CsfDPiGNQt4Gx7OqT3uzL6LB8rl WOBLZCEGDnrGMDGc3GDIZcp3M70iv9AayWbQBmNIm0aKwr2iAFlSVj72prO8xa+GSp /jbqoXpdcVzF/52YSGgGIFiANUZceqanytseY7ZY4cJw7Yih1pn3TLdLT63ylm40RM MEJJmMVjS2scw== Date: Tue, 22 Jul 2025 12:30:55 +0400 (+04) From: Ivan Malov To: Yoon Junghan cc: users@dpdk.org Subject: Re: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11) In-Reply-To: Message-ID: <3f7df93b-ee00-bcdb-337c-8faa7bd73f6c@arknetworks.am> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-201621043-1753173063=:7497" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-201621043-1753173063=:7497 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Hello, On Tue, 22 Jul 2025, Yoon Junghan wrote: > Hello, >   > I'm currently using DPDK 20.11 with a ConnectX-7 NIC, and I'm trying to retrieve RX hardware timestamps using `rte_mbuf_dyn_rx_timestamp_register()`. Does the application invoke 'rte_mbuf_dyn_rx_timestamp_register' on its own? If yes, consider to replace this with invocations of APIs [1] (with field name [2]) and [3] (with flag name [4]). For an example, please refer to [5] and [6]. This is because, as per [7], the driver in question might 'register' the field and the flag on its own, in response to 'DEV_RX_OFFLOAD_TIMESTAMP' request, so, the user application should look up the field/flag, not 'register' it afresh. If this does not help, then consider to clarify whether the timestamps are accurate (and whether the flag is seen in the mbufs) when LRO is not enabled. [1] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a6adf9b352a83e7d521fd6aa04e305b1c [2] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a5159b2d34fa801d171ed0ccce451121b [3] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a89d835027034f76a27eb2afe7987ae35 [4] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a831d7066c7193788351797a65186848a [5] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/app/test-pmd/util.c#L44 [6] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/app/test-pmd/util.c#L60 [7] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/drivers/net/mlx5/mlx5_rxq.c#L1743 Thank you. >   > When LRO is enabled, I notice that LROed mbufs seem to share identical timestamp values, and the timestamps are unexpectedly large or inconsistent. This raises the question of whether > LRO is interfering with the correctness of the RX HW timestamps. >   > I’d appreciate any clarification on whether HW RX timestamping is reliable when LRO is enabled on this platform, or if LRO should be just disabled for accurate per-packet timestamping. >   > > Sincerely, > Junghan Yoon > > --8323328-201621043-1753173063=:7497--