From: Ivan Malov <ivan.malov@arknetworks.am>
To: Yoon Junghan <cerotyki@gmail.com>
Cc: users@dpdk.org
Subject: Re: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11)
Date: Tue, 22 Jul 2025 12:30:55 +0400 (+04) [thread overview]
Message-ID: <3f7df93b-ee00-bcdb-337c-8faa7bd73f6c@arknetworks.am> (raw)
In-Reply-To: <b05b756f-d8ea-4b2b-a8bf-ea309efeff21@Spark>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
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
>
>
next prev parent reply other threads:[~2025-07-22 8:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 7:21 Yoon Junghan
2025-07-22 8:30 ` Ivan Malov [this message]
2025-07-22 8:46 ` Yoon Junghan
2025-07-23 12:43 ` Yoon Junghan
2025-07-23 13:09 ` Ivan Malov
2025-07-23 13:20 ` Yoon Junghan
2025-07-23 13:28 ` Ivan Malov
2025-07-23 13:50 ` Yoon Junghan
2025-07-23 14:19 ` Ivan Malov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f7df93b-ee00-bcdb-337c-8faa7bd73f6c@arknetworks.am \
--to=ivan.malov@arknetworks.am \
--cc=cerotyki@gmail.com \
--cc=users@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).