iavf_ptp_ex...2b_timestamp(9)

💖 NAME 💖

iavf_ptp_extend_32b_timestamp — Convert a 32b nanoseconds timestamp to 64b nanoseconds.

okay bestie, quick vibe check: we're in the Kernel API Manual, and this page is all about taking a teeny-tiny 32-bit nanoseconds timestamp and extending it into the 64-bit one the stack expects. ✨

✨ SYNOPSIS ✨

u64 iavf_ptp_extend_32b_timestamp (u64 cached_phc_time , u32 in_tstamp
);

🎀 ARGUMENTS 🎀

• cached_phc_time — recently cached copy of PHC time
• in_tstamp — Ingress/egress 32b nanoseconds timestamp value

🦋 DESCRIPTION 🦋

So here's the situation, bestie: hardware captures timestamps that contain only 32 bits of nominal nanoseconds, as opposed to the 64bit timestamps that the stack expects. 😭

To extend the 32bit nanosecond timestamp, we use this algorithm and these assumptions:

1. Have a recently cached copy of the PHC time.
2. Assume that the in_tstamp was captured 2^31 nanoseconds (~2.1 seconds) before or after the PHC time was captured.
3. Calculate the delta between the cached time and the timestamp.
4. If the delta is smaller than 2^31 nanoseconds, then the timestamp was captured after the PHC time. In this case, the full timestamp is just the cached PHC time plus the delta.
5. Otherwise, if the delta is larger than 2^31 nanoseconds, then the timestamp was captured before the PHC time, i.e. because the PHC cache was updated after the timestamp was captured by hardware. In this case, the full timestamp is the cached time minus the inverse delta.

This algorithm works even if the PHC time was updated after a Tx timestamp was requested, but before the Tx timestamp event was reported from hardware. 🔥

This calculation primarily relies on keeping the cached PHC time up to date. If the timestamp was captured more than 2^31 nanoseconds after the PHC time, it is possible that the lower 32bits of PHC time have overflowed more than once, and we might generate an incorrect timestamp. ⚠️

This is prevented by (a) periodically updating the cached PHC time once a second, and (b) discarding any Tx timestamp packet if it has waited for a timestamp for more than one second. 🫶

🌸 RETURN 🌸

extended timestamp (to 64b). 💅

🌈 SEE ALSO 🌈

Kernel file ./drivers/net/ethernet/intel/iavf/iavf_ptp.c

• iavf_ptp_disable_rx_tstamp(9)
• iavf_ptp_enable_rx_tstamp(9)
• iavf_ptp_set_timestamp_mode(9)
• iavf_ptp_set_ts_config(9)
• iavf_ptp_cap_supported(9)
• iavf_allocate_ptp_cmd(9)
• iavf_queue_ptp_cmd(9)
• iavf_send_phc_read(9)
• iavf_read_phc_indirect(9)
• iavf_ptp_cache_phc_time(9)
• iavf_ptp_do_aux_work(9)
• iavf_ptp_register_clock(9)
• iavf_ptp_init(9)
• iavf_ptp_release(9)
• iavf_ptp_process_caps(9)

---

That's the whole page, bestie. Source/version is ./drivers/net/ethernet/intel/iavf, and the date is October 2026 — go forth and extend those timestamps, periodt. 💖