Thread (32 messages) 32 messages, 4 authors, 2012-05-15

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

flat view

From: Richard Cochran <richardcochran@gmail.com>
Date: 2012-05-12 05:35:10

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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help