[linux-cifs-client] Re: sendmsg blocking with sendtimeout vs. non-blocking

Steve French smfrench at gmail.com
Thu Oct 23 19:40:01 GMT 2008


On Thu, Oct 23, 2008 at 2:35 PM, Jeff Layton <jlayton at redhat.com> wrote:
> On Thu, 23 Oct 2008 14:19:04 -0500
> "Steve French" <smfrench at gmail.com> wrote:
>> > His statement was basically "unless you know for sure that you don't
>> > want to use more than X amount of memory, then there isn't much reason
>> > to set the send and receive buffers".
>>
>> I think that there is a problem still - cifs needs tcp autotuning but
>> the buffers probably need to be at least as big as the largest SMB
>> response (about 17K on receives, but configurable to be larger).   See
>> comment below about NFS:
>>
>
> On Thu, Oct 23, 2008 at 2:05 PM, Jim Rees <rees at umich.edu> wrote:
>> There are two issues to be aware of.  One is that the socket buffers have to
>> be big enough for the tcp congestion window.  In the old days, the
>> application would have to know ahead of time how big this is, and call
>> setsockopt(), which sets these numbers.
>>
>> Now however, the tcp stack "autotunes" the buffer sizes to the correct
>> amount.  If you call setsockopt() to set a buffer size, or set sk_*buf, or
>> set the SOCK_*BUF_LOCK bits in sk_userlocks, you defeat this autotuning.
>> This is almost always a bad idea.
>>
>> The other issue is that at least for NFS, the receive buffer must be big
>> enough to hold the biggest possible rpc.  If not, a partial rpc will get
>> stuck in the buffer and no progress will be made.
>>
>> Issue one is easy to deal with, just don't muck with the socket internal
>> data structure.  The second one is harder.  What's really needed is a new
>> api into the tcp layer that will reserve a minimum amount of memory in the
>> socket buffer so that receives won't stall.  For now, our patch sets the
>> sk_*buf values without setting the lock flags.
>
>
> Agreed. Thanks Jim, for sending along that info...
>
> It sounds like what we should do for CIFS is the same thing. Set the
> buffer sizes but make sure the SOCK_*BUF_LOCK bits are cleared so that
> they can grow as needed.

CIFS, unlike NFS, never set the SOCK_*BUF_LOCK flags.

I think we already do the same thing as NFS, they still are turning
off autotuning on the client right?

If we could set a "sk_min_sndbuf_size" someday (to e.g. twice the size
of the cifs write frames ie about 112K)  - would that be enough?


-- 
Thanks,

Steve


More information about the linux-cifs-client mailing list