On Fri, Oct 24, 2008 at 09:59:36AM -0400, Jim Rees wrote: > Neil Horman wrote: > > Thats not true. Assuming there is sufficient memory available, and the tcp > segments receive window isn't closed, then you will continue to receive data, as > not setting SO_RCVBUF will allow the receive buffers to autotune in size. > > My explanation may be flawed but the behavior is real. If you turn on > autotuning on the nfsd socket, and don't do anything with the buffer sizes, > nfsd will stall. This is in a 2.6.24 kernel. I would of course welcome > independent verification. > I'll veryify when I get a chance, and I believe that what you say about nfsd is true, but I don't think its directly a result of autotuning (see below) > I thought that the receive buffer size would only grow as large as the > receiver's advertised window, but I'll admit I don't fully understand the > autotuning code. This is roughly correct, since thats as large as the buffer ever really needs to be. I say roughly because it will actually be somewhat larger than the window (allowing for skb overhead). I would need to verify this as well, but I would expect whats happening in the nfsd code is that by setting SO_RCVBUF, you are forcing the receive window to be sufficiently large to hold an entire rpc transaction. While this works, It does force the nfsd code to have some understanding of the underlying transport. It might be better (subject to much debate of course), to allocate a temporary buffer in the nfsd receve code that can hold a maximally sized rpc transaction, and simply call kernel_recvmsg with a timeout associated for whatever size you were expecting. You may get less than that back, but you can then store it in the temp buffer, update the appropriate pointers and sizes and call recvmsg again. that keeps the receive window open and data streaming in. Using the tcp receive buffer to force recives on application message boundaries is fraught with problems like this (in any application). Its better to use some extra ram to handle your application message reassembly. Neil -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman@xxxxxxxxxx *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
