Re: [RFC][PATCH 1/2] net: support for TX timestamps
From: Patrick Ohly <hidden>
Date: 2008-07-30 12:45:38
On Tue, 2008-07-29 at 03:35 +0300, Octavian Purdila wrote:
The actual timestamp will reach userspace as a RX timestamp on the cloned packet. If timestamping is requested and no timestamping is done in the device driver (potentially this may use hardware timestamping), it will be done in software after the device's start_hard_xmit routine.
This needs to be augmented to not fall back to software time stamping, as discussed in "[RFC][PATCH 1/1] net: support for hardware timestamping". Apart from that the API looks okay. It should be fairly simple to adapt PTPd.
quoted hunk ↗ jump to hunk
@@ -1568,6 +1576,8 @@ static int dev_gso_segment(struct sk_buff *skb) int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) { + int rc; + if (likely(!skb->next)) { if (!list_empty(&ptype_all)) dev_queue_xmit_nit(skb, dev);@@ -1579,13 +1589,15 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) goto gso; } - return dev->hard_start_xmit(skb, dev); + rc = dev->hard_start_xmit(skb, dev); + if (likely(!rc)) + net_tx_timestamp(skb); + return rc; }
How do you recognize whether the driver did hardware time stamping? Hmm, okay, I think I can answer that myself: if the driver supports hardware time stamping, it must clear tstamp in its hard_start_xmit(). Later on when it has transmitted the packet, it extracts the corresponding hardware time stamp and calls skb_tx_timestamp(). Right? If so, this should go into a comment somewhere. The implicit assumption here is that drivers do not touch tstamp, because otherwise software time stamping might accidentally be disabled by a driver. That seems to be the case, at least for in-kernel drivers. Is skb->sk always guaranteed to be set in hard_start_xmit? skb_tx_timestamp() depends on it. In 2.6.23 the field always seemed to be valid, but in 2.6.26 I think I have seen NULL pointers there for PTP UDP broadcasts. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.