netdev - Re: hardware time stamping with extra skb->hwtstamp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Nov 2008 16:02:15 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Patrick Ohly <patrick.ohly@...el.com>
Cc:	Oliver Hartkopp <oliver@...tkopp.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: hardware time stamping with extra skb->hwtstamp

From: Patrick Ohly <patrick.ohly@...el.com>
Date: Thu, 27 Nov 2008 11:07:07 +0100

> It certainly would be sufficient for PTP with the "assisted" PTP mode of
> synchronizing system time. But my understanding is that Octavian and
> possibly others want to have access to the raw, unmodified hardware time
> stamps. Octavian, perhaps you can confirm/elaborate what your use case
> is?

We use the hardware timestamp to determine one-way delay:
- hardware synchronize the NIC clocks (20ns resolution)
- insert the hw timestamp in the packet as its going out the wire (this is 
done in hw)
- received packets will be tagged with a hardware timestamp

One way delay is computed by subtracting the TX hw timestamp from the RX hw 
timestamp.

> To summarize, I see the following options at this time:
[snip]
> My personal preference is, in this order: 3, 4, 2b (current patch,
> but needs clean way to find network device), 1a.

I also vote for 3 (storing hw timestamps in the skb). 

Let me throw in another idea: when enabling hw timestamps could we allocate a 
bigger skb and store the hw timestamp somewhere in the skb data buffer? 

We can then modify sock_recv_timestamp to call a new netdev method which 
should return the hw timestamp. This should take care of RX hw timestamps.

For TX, we can we get a new skb with skb_copy_expand  to make room for the TX 
timestamp, and queue that in the error socket. 

There is still the problem of requesting TX timestamps per packets. At this 
point it seems that on the TX path the tstamp field is not used, so we could 
use that space. 

Or, maybe we can use the same dynamic approach: can we modify the 
hard_header_len after device registration (e.g. when TX timestamps are 
enabled)?

Thanks,
tavi

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html