netdev - Re: hardware time stamps + existing time stamp usage

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] [day] [month] [year] [list]

Date:	Tue, 21 Oct 2008 09:40:39 +0200
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Octavian Purdila <opurdila@...acom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Ingo Oeser <netdev@...eo.de>,
	"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: hardware time stamps + existing time stamp usage

On Tue, 2008-10-21 at 01:04 -0600, Andi Kleen wrote:
> > We can even compute the delta periodically now, to maintain better system -
> > hardware timestamps synchronization, as we can keep and multiple deltas (each
> > one associated with a modulo number).
> 
> The problem with this scheme is that it's unlikely to be precise enough to guarantee
> monoticity (that is that your delta clock compared to the system clock never goes
> backwards). And that tends to be a common requirements in system time stamps.
> Not having that would risk breaking existing applications.

Agreed. But even those users who need absolute monoticity would be able
to use PTP: at least the Intel hardware would be configured to only time
stamp PTP packets while the application packets that the user cares
about are still time stamped in software, as before.

> My recommendation would be to find some way to use a separate field and also
> use a separate API. That would also allow you to extend it (e.g. pass down
> the interface number), so that different time stamps from different interfaces
> are supported.

The latest proposal already uses such a separate API for HW time stamps,
so we are fine in that regard. In my opinion the API should only return
information which isn't available otherwise (currently the original HW
time stamp); the interface number should be returned with the existing
IP_PKTINFO.

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