Re: [net-next 06/12] ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC)

On 05/11/2012 10:34 PM, Richard Cochran wrote:

On Fri, May 11, 2012 at 07:23:44PM +0000, Keller, Jacob E wrote:

quoted

I believe this very rare case might be possible, but I don't think
that checking the ptp seqid will fix anything. In normal cases,
hardware latches Rx packet timestamp, then the ptp packet goes into
the queue and we process it shortly after. Before we process that
packet there will never be another packet in the queue that needs a
timestamp. We know this because the hardware stops timestamping
until we unlatch the RX registers. This should mean we don't need to
check the sequence ID, and spending time doing it would never fix
the issue you are talking about.

The issue is for when a packet is timestamped and then never reaches
the queue. Then the rx stamp registers are locked for good, because
we never clear them, and hardware would never timestamp another
receive packet. I don't know a good solution to this, except to
clear the registers periodically. Do you have any suggestions?

Well, one solution would be to check every received packet with the
BPF in ptp_classify.h (whenever Rx time stamping is enabled).

When the driver finds an event packet in the Rx queue, and
TSYNCRXCTL[RXTT] is set, it reads out the time stamp along with
RXSATRL/H. If the fields match, then add the time stamp to the skb.

[ Or perhaps instead of using RXSATRL/H, just use the descriptor bit.
   If *not* set, then the time stamp does not belong to this packet. ]

HTH,
Richard

Ok, this sounds like a good plan. Considering that the device already doesn't allow timestamping of other types of packets, so it doesn't need to be general purpose.

Am I correct in thinking all I need to do is check the type and if it matches the currently configured rx timestamp mode, then double check the bit for whether a timestamp is available, and whether the descriptor had a timestamp bit enabled?

Thanks

- Jake