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]

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

On Thu, 2008-11-27 at 14:02 +0000, Octavian Purdila wrote:
> From: Patrick Ohly <patrick.ohly@...el.com>
> Date: Thu, 27 Nov 2008 11:07:07 +0100
> > 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? 

How does the socket layer detect that the HW timestamp is available in
the larger skb data buffer, and where?

> 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.

Finding the netdev is non-trivial, see David's comment about the current
hacky approach via the route. Besides, if the time stamp is in the skb
data buffer, why is the netdev still needed? Do I miss something?

> 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. 

Agreed in general, but there was one corner case where the tstamp field
was set for looped multicast packets.

> 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)?

I don't know.

-- 
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.

--
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