From: Bruce Richardson <bruce.richardson@intel.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: <dev@dpdk.org>, Paul Greenwalt <paul.greenwalt@intel.com>,
"Vladimir Medvedkin" <vladimir.medvedkin@intel.com>
Subject: Re: [PATCH 0/2] net/iavf: handle PF not enabling Rx timestamps properly
Date: Mon, 17 Nov 2025 11:49:43 +0000 [thread overview]
Message-ID: <aRsL1yPeV12ZV-ae@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20251113-jk-dpdk-iavf-rx-timestamping-improvements-v1-0-3d9a0168087b@intel.com>
On Thu, Nov 13, 2025 at 01:33:43PM -0800, Jacob Keller wrote:
> 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
>
Series applied to dpdk-next-net-intel.
Thanks,
/Bruce
prev parent reply other threads:[~2025-11-17 11:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 21:33 Jacob Keller
2025-11-13 21:33 ` [PATCH 1/2] net/iavf: check if PF actually indicates Rx timestamps Jacob Keller
2025-11-17 11:37 ` Bruce Richardson
2025-11-13 21:33 ` [PATCH 2/2] net/iavf: check Rx timestamp validity bit Jacob Keller
2025-11-17 11:45 ` Bruce Richardson
2025-11-17 11:49 ` Bruce Richardson [this message]
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=aRsL1yPeV12ZV-ae@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jacob.e.keller@intel.com \
--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).