On Fri, 30 Sep 2022 08:52:38 +0000 Zulkifli, Muhammad Husaini wrote:

quoted

quoted

Yes. HW timestamps always can be assume equivalent to PTP quality.
Could you provide additional information regarding SFD crosses the RS  
layer?

I mean true PTP timestamps, rather than captured somewhere in the NIC
pipeline or at the DMA engine.  

When SOF_TIMESTAMPING_TX_HARDWARE is been used, we guaranteed a PTP quality
Timestamps (timestamp capture when packet leave the wire upon sensing the SFD).
As of SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH, it is not a PTP quality because
the HW timestamp reported in this case, is a time when the data is
DMA'ed into the NIC packet buffer.

I understand that _your_ device does it right.
But there are vendors out there who treat SOF_TIMESTAMPING_TX_HARDWARE
as your new SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH.

quoted

quoted

Yes, you're right. Are you suggesting that we add a new tx_type to
specify Only MAC/PHY timestamp ? Ex. HWTSTAMP_TX_PHY/MAC_ON.  

Perhaps we can call them HWTSTAMP_TX_PTP_* ? Was the general time
stamping requirement specified in IEEE 1588 or 802.1 (AS?)?

Both MAC and PHY can provide the time stamps IIUC, so picking one of those
will not be entirely fortunate. In fact perhaps embedded folks will use this
opportunity to disambiguate the two..  

With the help of SOF_TIMESTAMPING_TX_HARDWARE, we will get the 
PHY level timestamp(PTP quality) while using SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH,
we will get the timestamp at a point in the NIC pipeline.

Linuxptp application uses SOF_TIMESTAMPING_TX_HARDWARE for their socket option.
And this can guarantee a PTP quality timestamp. 

Can we just use a SOF_TIMESTAMPING to identify which timestamp that we want rather 
than creating a new tx_type?

Hm, perhaps, yes, we can stick to that.