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: Keller, Jacob E <jacob.e.keller@intel.com>
Date: 2012-05-11 18:05:57

-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Thursday, May 10, 2012 10:15 PM
To: Keller, Jacob E
Cc: Kirsher, Jeffrey T; davem@davemloft.net; <redacted>;
gospo@redhat.com; sassmann@redhat.com
Subject: Re: [net-next 06/12] ixgbe: Hardware Timestamping + PTP Hardware
Clock (PHC)

On Thu, May 10, 2012 at 09:53:18PM +0000, Keller, Jacob E wrote:
quoted
quoted
quoted
+	/*
+	 * If this bit is set, then the RX registers contain the time
stamp. No
quoted
quoted
quoted
+	 * other packet will be time stamped until we read these
registers, so
quoted
quoted
quoted
+	 * read the registers to make them available again. Because only
one
quoted
quoted
quoted
+	 * packet can be time stamped at a time, we know that the
register
quoted
quoted
quoted
+	 * values must belong to this one here and therefore we don't
need to
quoted
quoted
quoted
+	 * compare any of the additional attributes stored for it.
I suspect that this assumption is wrong. What happens if the time
stamping logic locks a value but the packet is lost because the ring is
full?
quoted
quoted
BTW, the IGB driver also has this defect.
Note how I read the rx registers first? So it will always clear the value.
That should unlock the value for the next rx stamp packet.
1. Hw recognizes ptp event packet, locks time stamp 2. Hw drops packet because
queue is full 3. No more time stamps are ever generated

Can this happen? The docs seems to say it can.

Richard
It might be possible. I'm curious what's the best method to solve this. I don't
think this generation of hardware can get an interrupt when the RX timestamp is
locked, and I don't know how easy it would be to process the sequence number within
the driver. It might be the case that the next packet would still be marked in the
descriptor and therefor the previous timestamp would apply to the next packet. I am
not sure, but I know we haven't seen issues where timestamps drop completely. This
is something I am not sure what's the best solution.

- Jake
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help