Re: [PATCH 2/2] net/iavf: check Rx timestamp validity bit

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Nov 13, 2025 at 01:33:45PM -0800, Jacob Keller wrote:
> 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.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---

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

Acked-by: Bruce Richardson <bruce.richardson@intel.com>