[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100501120641.GA18613@cel.leo>
Date: Sat, 1 May 2010 13:06:41 +0100
From: Paul LeoNerd Evans <leonerd@...nerd.org.uk>
To: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Cc: therbert@...gle.com
Subject: Re: [PATCH] tcp: SO_TIMESTAMP implementation for TCP
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@...nerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)
Powered by blists - more mailing lists