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]

Date:	Mon, 21 Apr 2008 03:59:39 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	andi@...stfloor.org
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

From: Andi Kleen <andi@...stfloor.org>
Date: Mon, 21 Apr 2008 12:44:56 +0200

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

Ask a financial service industry shop what the implications of
inaccurate transaction timestamps can be.  It possible for it to be
measured in the millions if not billions of euros.

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

So if tcpdump gets resceduled on another cpu, or the multiqueue flow
hashing algorithm changes, the appearance of the ordering of packets
changes.

No thanks.

Nobody wants half-working timestamps.  That's why it's such an
enormous issue that x86 screwed this up so badly for such a long
period of time.
--
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