netdev - Re: [RFC 0/4] net: enable timestamps on a per-socket basis

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: <87y7777ahj.fsf@basil.nowhere.org>
Date:	Mon, 21 Apr 2008 12:44:56 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	David Miller <davem@...emloft.net>
Cc:	juhlenko@...mai.com, netdev@...r.kernel.org,
	shemminger@...ux-foundation.org
Subject: Re: [RFC 0/4] net: enable timestamps on a per-socket basis

David Miller <davem@...emloft.net> writes:

> Moving the timestamp up to a higher level takes away some of the
> frequent use cases of timestamps, which is to detect things like the
> fact that it is taking a long time for packets to get from the
> top-level packet receive down to the actual protocol processing.

Is that really a frequent use case? It sounds more like a specialized
debugging situation. Most users are not network stack hackers :)

How about a sysctl to trigger between the two behaviours?
My guess would be that Jason's semantics are better for most systems.

> In fact, people are desiring timestamps which are _closer_ to when the
> device actually receives the frame rather than further away.

The other alternative was always to support loser time stamps especially
for networking. The reason people often complain about the time stamping
at all is when they use x86 systems with no globally reliable TSC which
has to fall back to slower southbridge timers and then they hurt.

But if you are willing to give away some of the guarantees of standard
gettimeofday (like global non monotonicity between CPUs) then you
could actually still use TSC even on those systems. And I don't
think global non monotonicity is really needed for a packet
time stamp ...

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