HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11)

HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11)

[Yoon Junghan]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

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()`.

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

[-- Attachment #2: Type: text/html, Size: 958 bytes --]

Re: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11)

[Ivan Malov]

[-- 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
> 
>

Re: HW RX timestamp with LRO enabled on ConnectX-7 (DPDK 20.11)

[Yoon Junghan]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

Thank you for your quick response!

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.

I'll quickly check the references you attached.

Sincerely,
Junghan Yoon
On Jul 22, 2025, 5:31 PM +0900, Ivan Malov <ivan.malov@arknetworks.am>, wrote:
> 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
> >

[-- Attachment #2: Type: text/html, Size: 3349 bytes --]