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

[luca.boccassi at gmail.com]

Hi,

FYI, your patch has been queued to stable release 22.11.11

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/22/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/bluca/dpdk-stable

This queued commit can be viewed at:
https://github.com/bluca/dpdk-stable/commit/2d320a4379ad166f34da03c7be02605d1ded1b72

Thanks.

Luca Boccassi

---
>From 2d320a4379ad166f34da03c7be02605d1ded1b72 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 4418b620c4..acace63096 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -1553,7 +1553,8 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
 		rxd_to_pkt_fields_ops[rxq->rxdid](rxq, rxm, &rxd);
 		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));
 
@@ -1722,7 +1723,8 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
 		rxd_to_pkt_fields_ops[rxq->rxdid](rxq, first_seg, &rxd);
 		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));
 
@@ -2007,7 +2009,8 @@ iavf_rx_scan_hw_ring_flex_rxd(struct iavf_rx_queue *rxq,
 			stat_err0 = rte_le_to_cpu_16(rxdp[j].wb.status_error0);
 			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 b56519a507..bdfb7c295d 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -611,6 +611,9 @@ enum iavf_tx_ctx_desc_tunnel_l4_tunnel_type {
 /* for iavf_32b_rx_flex_desc.pkt_len member */
 #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,
 			   uint16_t nb_desc,
-- 
2.47.3

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2025-11-20 12:44:13.012462859 +0000
+++ 0006-net-iavf-fix-Rx-timestamp-validity-check.patch	2025-11-20 12:44:12.778087984 +0000
@@ -1 +1 @@
-From dba51a2fbdde67a2237a8d2c9fb73baf29e04dd0 Mon Sep 17 00:00:00 2001
+From 2d320a4379ad166f34da03c7be02605d1ded1b72 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
-@@ -1582,7 +1582,8 @@ 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 4418b620c4..acace63096 100644
+--- a/drivers/net/iavf/iavf_rxtx.c
++++ b/drivers/net/iavf/iavf_rxtx.c
+@@ -1553,7 +1553,8 @@ iavf_recv_pkts_flex_rxd(void *rx_queue,
@@ -75 +76 @@
-@@ -1751,7 +1752,8 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
+@@ -1722,7 +1723,8 @@ iavf_recv_scattered_pkts_flex_rxd(void *rx_queue, struct rte_mbuf **rx_pkts,
@@ -85 +86 @@
-@@ -2036,7 +2038,8 @@ iavf_rx_scan_hw_ring_flex_rxd(struct ci_rx_queue *rxq,
+@@ -2007,7 +2009,8 @@ iavf_rx_scan_hw_ring_flex_rxd(struct iavf_rx_queue *rxq,
@@ -95,5 +96,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
-@@ -504,6 +504,9 @@ 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 b56519a507..bdfb7c295d 100644
+--- a/drivers/net/iavf/iavf_rxtx.h
++++ b/drivers/net/iavf/iavf_rxtx.h
+@@ -611,6 +611,9 @@ enum iavf_tx_ctx_desc_tunnel_l4_tunnel_type {