From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
To: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Cc: therbert@google.com
Subject: Re: [PATCH] tcp: SO_TIMESTAMP implementation for TCP
Date: Sat, 1 May 2010 13:06:41 +0100 [thread overview]
Message-ID: <20100501120641.GA18613@cel.leo> (raw)
In-Reply-To: <20100430.164115.257514715.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
On Fri, Apr 30, 2010 at 04:41:15PM -0700, David Miller wrote:
> If other people have an opinion about this, now would be the time
> to speak up. :-)
I have to say I agree with David.
The "receive timestamp" for a TCP recv() call is completely meaningless.
Each byte in the stream arguably could have a set of receive timestamps,
being the timestamp of the underlying IPv4 packet containing a fragment
of a TCP segment that covered that byte. One recv() call could cover
many packets, many recv() calls could be required to consume one packet.
We just don't know from userland.
The point about IPv4 fragments in UDP is a reasonable one; that because
of IPv4 fragmentation there are still potentially multiple timestamps
that could be relevant to a single UDP recv() call. But no two recv()
calls can possibly relate to the same IPv4 fragments, so I feel this is
more defined. Plus, of all the IPv4 fragments that go into a single UDP
packet, one of them is special - the first one, the one containing the
UDP header. We could easily say "the timestamp of a UDP recv() call
shall be the time at which its header was received, even if other
fragments arrived before or after it".
We cannot make any such distinction for some window in a TCP stream. All
TCP segments are indistinct in this manner.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
prev parent reply other threads:[~2010-05-01 12:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 6:07 [PATCH] tcp: SO_TIMESTAMP implementation for TCP Tom Herbert
2010-04-30 6:39 ` David Miller
2010-04-30 7:58 ` Tom Herbert
2010-04-30 23:41 ` David Miller
2010-05-01 5:07 ` Bill Fink
2010-05-01 5:40 ` Tom Herbert
2010-05-01 6:00 ` Eric Dumazet
2010-05-01 5:31 ` Tom Herbert
2010-05-01 12:06 ` Paul LeoNerd Evans [this message]
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=20100501120641.GA18613@cel.leo \
--to=leonerd@leonerd.org.uk \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/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).