ice_ptp_process_tx_tstamp(9)

📦 version 7.3.1, in nixpkgs unstable

💖 ice_ptp_process_tx_tstamp(9) 💖

okay bestie, welcome to the Kernel API Manual — this is the page for ice_ptp_process_tx_tstamp, and it's genuinely a little baddie for Tx timestamps. 🫶✨

🌸 NAME 🌸

ice_ptp_process_tx_tstamp - Process Tx timestamps for a port 💅

🎀 SYNOPSIS 🎀

void ice_ptp_process_tx_tstamp (struct ice_ptp_tx *tx );

🦋 ARGUMENTS 🦋

  • tx — the PTP Tx timestamp tracker, aka the main character of this function 🎯

✨ DESCRIPTION ✨

So this function processes the timestamps captured by the PHY that's associated with this port. The way it does that? It loops over each index that has a waiting skb. 🌀

If a given index has a valid timestamp, it does these seven steps, in order:

  1. check that the timestamp request is not stale 👵
  2. check that a timestamp is ready and available in the PHY memory bank 🏦
  3. read and copy the timestamp out of the PHY register 📖
  4. unlock the index by clearing the associated in_use bit 🔓
  5. check if the timestamp is stale, and discard it if so 💀
  6. extend the 40 bit timestamp value to get a 64 bit timestamp value 🧮
  7. send this 64 bit timestamp to the stack 📤
important note bestie: we do not hold the tracking lock while reading the Tx timestamp. Why? because reading the timestamp requires taking a mutex that might sleep 😴.

The only place where in_use gets set is when a new timestamp is initiated with a slot index. That only happens in the hard xmit routine when an SKB has a request flag set. The only places where this bit gets cleared are this function, or during teardown when the Tx timestamp tracker is being removed. A timestamp index will never be re-used until the in_use bit for that index is cleared. 🚫🔁

If a Tx thread starts a new timestamp, we might not begin processing it right away, but we will notice it at the end when we re-queue the task. ⏳

If a Tx thread starts a new timestamp just after this function exits, the interrupt for that timestamp should re-trigger this function once a timestamp is ready. ⚡

In cases where the PTP hardware clock was directly adjusted, some timestamps may not be able to safely use the timestamp extension math. In that case, software will set the stale bit for any outstanding Tx timestamps when the clock is adjusted. Then this function will discard those captured timestamps instead of sending them to the stack. 🕰️💔

If a Tx packet has been waiting for more than 2 seconds, it is not possible to correctly extend the timestamp using the cached PHC time. It is extremely unlikely that a packet will ever take this long to timestamp. If we detect a Tx timestamp request that has waited for this long, we assume the packet will never be sent by hardware and discard it without reading the timestamp register. ⏱️🙅‍♀️

🌈 SEE ALSO 🌈

Kernel file: ./drivers/net/ethernet/intel/ice/ice_ptp.c — the source bestie, go read it if you're nosy 📂👀

mwah 💋 source/version: ./drivers/net/ethernet/intel/ice; date: October 2026; and yes bestie, this is still ice_ptp_process_tx_tstamp(9) saying byeeeee 🫶✨

📦 where this page comes from