[PATCH] net/iavf: negotiate PTP with PF before reporting Rx timestamping

[PATCH] net/iavf: negotiate PTP with PF before reporting Rx timestamping

[Jacob Keller]

The iavf driver has support for hardware Rx timestamps since commit h
b5cd735132f6 ("net/iavf: enable Rx timestamp on flex descriptor").

To enable this, the VF must first negotiate PTP capabilities with the PF
by sending the VIRTCHNL_OP_1588_PTP_GET_CAPS command, with the requested
capabilities. The PF will respond with the actually supported subset of
capabilities.

The PF may not actually enable Rx timestamping, even if it reports the
overall PTP capability support. If this happens, the iavf driver logic
will incorrectly report that Rx timestamps can be enabled despite being
rejected by the PF.

This should be unlikely in practice, as most PFs which support the
VIRTCHNL_VF_CAP_PTP will support Rx timestamping. However, there are
some cases where this may not be true. In particular, there is an
unfortunate issue with some versions of the ice PF using a different
structure layout that prevents the PF from enabling Rx timestamping.

To prevent this, the DPDK driver should check the capabilities and
confirm that the PF did enable Rx timestamping, instead of assuming it
will be enabled by all PFs that support the VIRTCHNL_CAP_PTP feature.
This prevents the DPDK application from attempting to enable Rx
timestamps when the PF will not support it.

Currently, the DPDK driver only negotiates PTP capabilities when the
device is started. First, check the capabilities during iavf_dev_init()
so that the iavf_dev_info_get() function has the required knowledge.
Then, only set RTE_ETH_RX_OFFLOAD_TIMESTAMP when the PF has informed
that it enabled support.

Continue to re-check the PTP capabilities in iavf_dev_start(), as it is
important to renegotiate after device reset.

Fixes: d21c2fe6e5a1 ("net/iavf: fix check for PF Rx timestamp support")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
This is a new version of the fix to prevent enabling Rx timestamps on PFs
which do not enable it when negotiating capabilities. It combines the
original fix along with the additional requirement of negotiating the PTP
capabilities during iavf_dev_init().
---

---
 drivers/net/intel/iavf/iavf_ethdev.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/intel/iavf/iavf_ethdev.c b/drivers/net/intel/iavf/iavf_ethdev.c
index 15e49fe24814..9b07b11a6b51 100644
--- a/drivers/net/intel/iavf/iavf_ethdev.c
+++ b/drivers/net/intel/iavf/iavf_ethdev.c
@@ -1177,7 +1177,8 @@ iavf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
 	if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_CRC)
 		dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_KEEP_CRC;
 
-	if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_PTP)
+	if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_PTP &&
+	    vf->ptp_caps & VIRTCHNL_1588_PTP_CAP_RX_TSTAMP)
 		dev_info->rx_offload_capa |= RTE_ETH_RX_OFFLOAD_TIMESTAMP;
 
 	if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_OFFLOAD_VLAN_V2 &&
@@ -2886,6 +2887,14 @@ iavf_dev_init(struct rte_eth_dev *eth_dev)
 		}
 	}
 
+	/* Get PTP caps early to verify device capabilities */
+	if (vf->vf_res->vf_cap_flags & VIRTCHNL_VF_CAP_PTP) {
+		if (iavf_get_ptp_cap(adapter)) {
+			PMD_INIT_LOG(ERR, "Failed to get ptp capability");
+			goto security_init_err;
+		}
+	}
+
 	iavf_default_rss_disable(adapter);
 
 	iavf_dev_stats_reset(eth_dev);

---
base-commit: cd60dcd503b91956f966a1f6d595b35d256ac00f
change-id: 20251121-jk-dpdk-iavf-rx-timestamping-fix-abdcb42f0197

Best regards,
--  
Jacob Keller <jacob.e.keller@intel.com>

Re: [PATCH] net/iavf: negotiate PTP with PF before reporting Rx timestamping

[Bruce Richardson]

On Wed, Dec 10, 2025 at 01:45:52PM -0800, Jacob Keller wrote:
> The iavf driver has support for hardware Rx timestamps since commit h
> b5cd735132f6 ("net/iavf: enable Rx timestamp on flex descriptor").
> 
> To enable this, the VF must first negotiate PTP capabilities with the PF
> by sending the VIRTCHNL_OP_1588_PTP_GET_CAPS command, with the requested
> capabilities. The PF will respond with the actually supported subset of
> capabilities.
> 
> The PF may not actually enable Rx timestamping, even if it reports the
> overall PTP capability support. If this happens, the iavf driver logic
> will incorrectly report that Rx timestamps can be enabled despite being
> rejected by the PF.
> 
> This should be unlikely in practice, as most PFs which support the
> VIRTCHNL_VF_CAP_PTP will support Rx timestamping. However, there are
> some cases where this may not be true. In particular, there is an
> unfortunate issue with some versions of the ice PF using a different
> structure layout that prevents the PF from enabling Rx timestamping.
> 
> To prevent this, the DPDK driver should check the capabilities and
> confirm that the PF did enable Rx timestamping, instead of assuming it
> will be enabled by all PFs that support the VIRTCHNL_CAP_PTP feature.
> This prevents the DPDK application from attempting to enable Rx
> timestamps when the PF will not support it.
> 
> Currently, the DPDK driver only negotiates PTP capabilities when the
> device is started. First, check the capabilities during iavf_dev_init()
> so that the iavf_dev_info_get() function has the required knowledge.
> Then, only set RTE_ETH_RX_OFFLOAD_TIMESTAMP when the PF has informed
> that it enabled support.
> 
> Continue to re-check the PTP capabilities in iavf_dev_start(), as it is
> important to renegotiate after device reset.
> 
> Fixes: d21c2fe6e5a1 ("net/iavf: fix check for PF Rx timestamp support")
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> This is a new version of the fix to prevent enabling Rx timestamps on PFs
> which do not enable it when negotiating capabilities. It combines the
> original fix along with the additional requirement of negotiating the PTP
> capabilities during iavf_dev_init().
> ---
> 
> ---
>  drivers/net/intel/iavf/iavf_ethdev.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Applied to dpdk-next-net-intel,

Thanks,
/Bruce