<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div>Thank you for your quick response!</div>
<div> </div>
<div>FYI, I've already tried retrieving RX hardware timestamp without LRO, and confirmed it works well. Inter arrival time of packets was about 10ns~50ns in average.</div>
<div> </div>
<div>I'll quickly check the references you attached.</div>
</div>
<div name="messageSignatureSection"><br />
<div>Sincerely,</div>
<div>Junghan Yoon</div>
</div>
<div name="messageReplySection">On Jul 22, 2025, 5:31 PM +0900, Ivan Malov <ivan.malov@arknetworks.am>, wrote:<br />
<blockquote type="cite">Hello,<br />
<br />
On Tue, 22 Jul 2025, Yoon Junghan wrote:<br />
<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">Hello,<br />
<br />
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()`.<br /></blockquote>
<br />
Does the application invoke 'rte_mbuf_dyn_rx_timestamp_register' on its own? If<br />
yes, consider to replace this with invocations of APIs [1] (with field name [2])<br />
and [3] (with flag name [4]). For an example, please refer to [5] and [6].<br />
<br />
This is because, as per [7], the driver in question might 'register' the field<br />
and the flag on its own, in response to 'DEV_RX_OFFLOAD_TIMESTAMP' request, so,<br />
the user application should look up the field/flag, not 'register' it afresh.<br />
<br />
If this does not help, then consider to clarify whether the timestamps are<br />
accurate (and whether the flag is seen in the mbufs) when LRO is not enabled.<br />
<br />
[1] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a6adf9b352a83e7d521fd6aa04e305b1c<br />
[2] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a5159b2d34fa801d171ed0ccce451121b<br />
[3] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a89d835027034f76a27eb2afe7987ae35<br />
[4] https://doc.dpdk.org/api-20.11/rte__mbuf__dyn_8h.html#a831d7066c7193788351797a65186848a<br />
[5] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/app/test-pmd/util.c#L44<br />
[6] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/app/test-pmd/util.c#L60<br />
[7] https://github.com/DPDK/dpdk/blob/d69724b1dcc69784bcef00b96597469b7f6e6207/drivers/net/mlx5/mlx5_rxq.c#L1743<br />
<br />
Thank you.<br />
<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;"> <br />
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<br />
LRO is interfering with the correctness of the RX HW timestamps.<br />
<br />
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.<br />
<br />
<br />
Sincerely,<br />
Junghan Yoon<br />
<br /></blockquote>
</blockquote>
</div>
</body>
</html>