netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: andi@firstfloor.org
Cc: juhlenko@akamai.com, netdev@vger.kernel.org,
	shemminger@linux-foundation.org
Subject: Re: [RFC 0/4] net: enable timestamps on a per-socket basis
Date: Mon, 21 Apr 2008 03:59:39 -0700 (PDT)	[thread overview]
Message-ID: <20080421.035939.37324583.davem@davemloft.net> (raw)
In-Reply-To: <87y7777ahj.fsf@basil.nowhere.org>

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

> David Miller <davem@davemloft.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.

  reply	other threads:[~2008-04-21 10:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-21  5:34 [RFC 0/4] net: enable timestamps on a per-socket basis Jason Uhlenkott
2008-04-21  5:34 ` [RFC 1/4] net core: move timestamp functions Jason Uhlenkott
2008-04-21  5:35 ` [RFC 2/4] net core: let protocols implement SOCK_TIMESTAMP efficiently Jason Uhlenkott
2008-04-21  5:35 ` [RFC 3/4] ipv4: efficient SOCK_TIMESTAMP support for TCP, UDP, and raw sockets Jason Uhlenkott
2008-04-21  5:36 ` [RFC 4/4] af_packet: efficient SOCK_TIMESTAMP support Jason Uhlenkott
2008-04-21  6:03 ` [RFC 0/4] net: enable timestamps on a per-socket basis David Miller
2008-04-21  7:28   ` Jason Uhlenkott
2008-04-21 10:44   ` Andi Kleen
2008-04-21 10:59     ` David Miller [this message]
2008-04-21 11:43       ` Andi Kleen
2008-04-21 11:51         ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080421.035939.37324583.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=andi@firstfloor.org \
    --cc=juhlenko@akamai.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).