DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: dev@dpdk.org
Cc: Paul Greenwalt <paul.greenwalt@intel.com>,
	 Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
	 Jacob Keller <jacob.e.keller@intel.com>
Subject: [PATCH 0/2] net/iavf: handle PF not enabling Rx timestamps properly
Date: Thu, 13 Nov 2025 13:33:43 -0800	[thread overview]
Message-ID: <20251113-jk-dpdk-iavf-rx-timestamping-improvements-v1-0-3d9a0168087b@intel.com> (raw)

In certain cases, the PF for the iavf driver may support
VIRTCHNL_VF_CAP_PTP but will not enable Rx timestamps. If this occurs, the
iavf driver will attempt to continue anyways. When that happens, the
resulting timestamps will appear to function initially. Upon closer
inspection it becomes clear that the timestamps are invalid and bogus.

First, when reporting a timestamp, always check the validity bit instead of
blindly reporting it. This avoids extending an invalid (likely zero'd)
timestamp value from the Rx descriptor.

Second, don't enable the RTE_ETH_RX_OFFLOAD_TIMESTAMP capability if the PF
doesn't indicate we have support. This will prevent applications from
trying to timestamp when it is not properly enabled.

Typically, this should not happen, as the PFs which support
VIRTCHNL_VF_CAP_PTP should support Rx timestamping. However, we recently
discovered a flaw in some implementations of the
VIRTCHNL_OP_1588_PTP_GET_CAPS command. The layout of the capabilities
structure is incorrect, with the caps member placed at a different byte
offset than the expected structure layout. This is the case with the
upstream Linux ice PF driver.

This results in the PF rejecting the request for Rx timestamping, and
leaving timestamping disabled. A proper fix for this situation is
difficult. If we merely changed the structure layout in DPDK, then it would
stop being compatible with other host OSes and with other implementations
of the Linux ice PF. If we changed the layout upstream, it would break
compatibility with the upstream iAVF VF driver.

A proper fix to resolve this will take some time, as we will likely have to
introduce a new flag or ops capability across many drivers. In the mean
time, we should at least make sure the DPDK driver stops reporting bogus
timestamps in such a setup.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
Jacob Keller (2):
      net/iavf: check if PF actually indicates Rx timestamps
      net/iavf: check Rx timestamp validity bit

 drivers/net/intel/iavf/iavf_rxtx.h   | 3 +++
 drivers/net/intel/iavf/iavf_ethdev.c | 3 ++-
 drivers/net/intel/iavf/iavf_rxtx.c   | 9 ++++++---
 3 files changed, 11 insertions(+), 4 deletions(-)
---
base-commit: be0112878b4fc3a1b918370ed2fe615c52039d77
change-id: 20251113-jk-dpdk-iavf-rx-timestamping-improvements-a06d21385371

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


             reply	other threads:[~2025-11-13 21:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13 21:33 Jacob Keller [this message]
2025-11-13 21:33 ` [PATCH 1/2] net/iavf: check if PF actually indicates Rx timestamps Jacob Keller
2025-11-13 21:33 ` [PATCH 2/2] net/iavf: check Rx timestamp validity bit Jacob Keller

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=20251113-jk-dpdk-iavf-rx-timestamping-improvements-v1-0-3d9a0168087b@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=dev@dpdk.org \
    --cc=paul.greenwalt@intel.com \
    --cc=vladimir.medvedkin@intel.com \
    /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).