patch 'net/iavf: fix Rx timestamp validity check' has been queued to stable release 24.11.4

[Kevin Traynor]

Hi,

FYI, your patch has been queued to stable release 24.11.4

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 11/26/25. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/eb5dc1ca76c40f05514251982a21a4d77b6d709f

Thanks.

Kevin

---
>From eb5dc1ca76c40f05514251982a21a4d77b6d709f Mon Sep 17 00:00:00 2001
From: Jacob Keller <jacob.e.keller at intel.com>
Date: Thu, 13 Nov 2025 13:33:45 -0800
Subject: [PATCH] net/iavf: fix Rx timestamp validity check

[ upstream commit dba51a2fbdde67a2237a8d2c9fb73baf29e04dd0 ]

When reporting an Rx timestamp from the receive descriptor, the iavf
driver does not check the validity bit in the time_stamp_low field. In
the event that hardware does not capture a receive timestamp for any
reason, this valid bit is unset, and the timestamp value in the
descriptor is zeroed out.

The iavf driver ignores this and passes the zero value into the
iavf_tstamp_convert_32b_64b function regardless, and proceeds to treat
the result as a valid timestamp.

Instead of reporting a zero timestamp which users can clearly interpret
as invalid, the raw 0 value from the descriptor is "extended" to the
64-bit timestamp. This results in values which are not immediately
obvious as invalid to users:

  timestamp 1760629088881475583
  timestamp 1760629088881475583
  timestamp 1760629088881475583

First, if the value is printed in base 10 it is not immediately obvious
that the lower 32 bits are zero. Second, multiple packets in sequence
will receive the same "timestamp".

This occurs because of the timestamp extension logic. The receive
descriptor timestamps are 40 bits, with 32 bits of nanosecond precision,
7 bits of subnanosecond precision, and 1 validity bit. The
sub-nanosecond precision bits are discarded. To obtain a 64-bit
timestamp, the upper 32 bits are calculated from the lower 32-bits and a
snapshot of the PHC timer that is captured recently (within ~2 seconds
of the packet timestamp). This enables reporting proper full 64-bit
timestamps without needing to store all 64 bits in the receive
descriptor.

However, when timestamps are not working properly, the raw 'zero' value
is extended regardless of whether hardware indicated it was a valid
timestamp. As a result, users can see what appear at a glance as valid
timestamps. However, they will not match the packet reception time, and
will only update when the upper bits would roll over. This occurs every
2^32 seconds, or approximately once every 4 seconds.

Instead of reporting bogus extended timestamp values which could confuse
user applications, check the validity bit and only report a timestamp of
the valid bit is set. This matches the implementation used in the Linux
PF driver.

Fixes: b5cd735132f6 ("net/iavf: enable Rx timestamp on flex descriptor")

Signed-off-by: Jacob Keller <jacob.e.keller at intel.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
---
 drivers/net/iavf/iavf_rxtx.c | 9 ++++++---
 drivers/net/iavf/iavf_rxtx.h | 3 +++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 8fdf0f92e2..a2e51cc310 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -1623,5 +1623,6 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
 		pkt_flags = iavf_flex_rxd_error_to_pkt_flags(rx_stat_err0);
 
-		if (iavf_timestamp_dynflag > 0) {
+		if (iavf_timestamp_dynflag > 0 &&
+		    rxd.wb.time_stamp_low & IAVF_RX_FLX_DESC_TS_VALID) {
 			ts_ns = iavf_tstamp_convert_32b_64b(rxq->phc_time,
 				rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high));
@@ -1792,5 +1793,6 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
 		pkt_flags = iavf_flex_rxd_error_to_pkt_flags(rx_stat_err0);
 
-		if (iavf_timestamp_dynflag > 0) {
+		if (iavf_timestamp_dynflag > 0 &&
+		    rxd.wb.time_stamp_low & IAVF_RX_FLX_DESC_TS_VALID) {
 			ts_ns = iavf_tstamp_convert_32b_64b(rxq->phc_time,
 				rte_le_to_cpu_32(rxd.wb.flex_ts.ts_high));
@@ -2077,5 +2079,6 @@ iavf_rx_scan_hw_ring_flex_rxd(struct iavf_rx_queue *rxq,
 			pkt_flags = iavf_flex_rxd_error_to_pkt_flags(stat_err0);
 
-			if (iavf_timestamp_dynflag > 0) {
+			if (iavf_timestamp_dynflag > 0 &&
+			    rxdp[j].wb.time_stamp_low & IAVF_RX_FLX_DESC_TS_VALID) {
 				ts_ns = iavf_tstamp_convert_32b_64b(rxq->phc_time,
 					rte_le_to_cpu_32(rxdp[j].wb.flex_ts.ts_high));
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index ef8aab4e9d..1237c54f82 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -644,4 +644,7 @@ enum iavf_tx_ctx_desc_tunnel_l4_tunnel_type {
 #define IAVF_RX_FLX_DESC_PKT_LEN_M	(0x3FFF) /* 14-bits */
 
+/* Valid indicator bit for the time_stamp_low field */
+#define IAVF_RX_FLX_DESC_TS_VALID	(0x1UL)
+
 int iavf_dev_rx_queue_setup(struct rte_eth_dev *dev,
 			   uint16_t queue_idx,
-- 
2.51.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-11-21 11:05:11.874956463 +0000
+++ 0074-net-iavf-fix-Rx-timestamp-validity-check.patch	2025-11-21 11:05:09.554201557 +0000
@@ -1 +1 @@
-From dba51a2fbdde67a2237a8d2c9fb73baf29e04dd0 Mon Sep 17 00:00:00 2001
+From eb5dc1ca76c40f05514251982a21a4d77b6d709f Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit dba51a2fbdde67a2237a8d2c9fb73baf29e04dd0 ]
+
@@ -52 +53,0 @@
-Cc: stable at dpdk.org
@@ -57,2 +58,2 @@
- drivers/net/intel/iavf/iavf_rxtx.c | 9 ++++++---
- drivers/net/intel/iavf/iavf_rxtx.h | 3 +++
+ drivers/net/iavf/iavf_rxtx.c | 9 ++++++---
+ drivers/net/iavf/iavf_rxtx.h | 3 +++
@@ -61,5 +62,5 @@
-diff --git a/drivers/net/intel/iavf/iavf_rxtx.c b/drivers/net/intel/iavf/iavf_rxtx.c
-index ea49059f83..d8662fd815 100644
---- a/drivers/net/intel/iavf/iavf_rxtx.c
-+++ b/drivers/net/intel/iavf/iavf_rxtx.c
-@@ -1583,5 +1583,6 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
+diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
+index 8fdf0f92e2..a2e51cc310 100644
+--- a/drivers/net/iavf/iavf_rxtx.c
++++ b/drivers/net/iavf/iavf_rxtx.c
+@@ -1623,5 +1623,6 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
@@ -73 +74 @@
-@@ -1752,5 +1753,6 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
+@@ -1792,5 +1793,6 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -81 +82 @@
-@@ -2037,5 +2039,6 @@ iavf_rx_scan_hw_ring_flex_rxd(struct ci_rx_queue *rxq,
+@@ -2077,5 +2079,6 @@ iavf_rx_scan_hw_ring_flex_rxd(struct iavf_rx_queue *rxq,
@@ -89,5 +90,5 @@
-diff --git a/drivers/net/intel/iavf/iavf_rxtx.h b/drivers/net/intel/iavf/iavf_rxtx.h
-index 5c9339b99f..8efb3bd04e 100644
---- a/drivers/net/intel/iavf/iavf_rxtx.h
-+++ b/drivers/net/intel/iavf/iavf_rxtx.h
-@@ -505,4 +505,7 @@ enum iavf_tx_ctx_desc_tunnel_l4_tunnel_type {
+diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
+index ef8aab4e9d..1237c54f82 100644
+--- a/drivers/net/iavf/iavf_rxtx.h
++++ b/drivers/net/iavf/iavf_rxtx.h
+@@ -644,4 +644,7 @@ enum iavf_tx_ctx_desc_tunnel_l4_tunnel_type {