David S. Miller wrote: >From: Chase Douglas <[EMAIL PROTECTED]> >Date: Mon, 11 Jul 2005 12:33:46 -0500 > > > >>I'm sorry, I made a careless mistake in choice of context. What this would >>be useful for is applications where we want to seek ahead in one stream from >>one connection. This is not meant for seeking somehow between multiple >>connections, but for one single connection between only two computers. >> >> > >What do you do is the data you want is beyond the size of >the socket's receive buffer? You can't seek past that without >allowing the socket to go over it's receive buffer limits. >And if you limit the seek to the receive buffer limit, that's >a real grotty limitation and it's not real seek() support on >the stream. > > If the seek is beyond the size of the seek buffer, then an error message is returned. Right now, I'm returning -ENOSR which prints socket out of stream resources. As long as you are within reason, you should be able to blow up your receive buffer and seek at least 1 MB ahead, and I have gotten 10 MB ahead when I tested a while ago, though it wasn't consistent due to bugs in the implementation. This amount should be quite enough room to do meaningful seeks.
If, however, you want data beyond what the queue can hold, you can either receive conventionally to get to that data, or delete bytes from the stream without copying to get to the data. I have benchmark data, though rather synthetic, showing the benefits of this. One of the benchmarks seeks 1MB ahead, pulls 1 MB, then pulls the first 1 MB, then repeats this 1000 times. I see an over all time decrease of 9.0%, a user time decrease of 99.5% (due to no user-user copying), and a system time decrease of 10.2% when compared to a normal, non-seeking receive which copies the first 1 MB to user, then copies the second 1 MB to user, then copies the first 1 MB from user to user buffers to simulate what an intermediate library would have to do. This may not mean much for normal use, but there are academic instances, especially in cluster computing, where saving many extra user-user copies can really add up. Thanks - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
