[linux-cifs-client] Re: [PATCH 6/6] cifs: don't retry on blocking
sends
Steve French
smfrench at gmail.com
Mon Dec 1 01:02:22 GMT 2008
Presumably there is slightly less overhead (since 99%+ of all tcp
kernel send message calls don't timeout/retry) in not having to reset
the send timeout over and over. We need a longer send timeout for
large writes (> 56K) than for typical requests (100 bytes or so for
the header is all that is sent)... so presumably is more efficient to
set a low timeout (somewhere from 1 to 5 seconds) and retry a few
times for the large write case.
On Sun, Nov 30, 2008 at 4:18 PM, Jeff Layton <jlayton at redhat.com> wrote:
> On Sun, 30 Nov 2008 15:39:17 -0600
> "Steve French" <smfrench at gmail.com> wrote:
>
>> We probably do need to retry, but closer to the 20 second range total which
>> is only slightly longer than the large (non-blocking) send retry used to wait.
>>
>
> I'm not sure I understand this. Why would we need to ever retry the
> send? Why not just set the timeout to the value we want and let kernel_sendmsg
> do the work?
>
> The timeout value is certainly negotiable though...
>
>> On Sun, Nov 30, 2008 at 7:57 AM, Jeff Layton <jlayton at redhat.com> wrote:
>> > smb_send2 will attempt to send a message and retry if it doesn't work.
>> > It's rather pointless to do this in the case of blocking sends. We can
>> > just set the socket sndtimeo to a reasonable value and try the send
>> > once.
>> >
>> > Why change the timeout to 30s? That seems like a reasonable amount of
>> > time to wait for the send. It's also what sunrpc uses for sndtimeo
>> > with TCP sockets. At some point we might consider making this
>> > tunable, but a generic "timeo" setting similar to what NFS has is
>> > probably more user friendly.
>> >
>> > Signed-off-by: Jeff Layton <jlayton at redhat.com>
>> > ---
>> > fs/cifs/connect.c | 4 ++--
>> > fs/cifs/transport.c | 12 ++++++++++++
>> > 2 files changed, 14 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>> > index 25f7cba..16afe2d 100644
>> > --- a/fs/cifs/connect.c
>> > +++ b/fs/cifs/connect.c
>> > @@ -1753,7 +1753,7 @@ ipv4_connect(struct TCP_Server_Info *server)
>> > * user space buffer
>> > */
>> > socket->sk->sk_rcvtimeo = 7 * HZ;
>> > - socket->sk->sk_sndtimeo = 3 * HZ;
>> > + socket->sk->sk_sndtimeo = 30 * HZ;
>> >
>> > /* make the bufsizes depend on wsize/rsize and max requests */
>> > if (server->noautotune) {
>> > @@ -1904,7 +1904,7 @@ ipv6_connect(struct TCP_Server_Info *server)
>> > * user space buffer
>> > */
>> > socket->sk->sk_rcvtimeo = 7 * HZ;
>> > - socket->sk->sk_sndtimeo = 3 * HZ;
>> > + socket->sk->sk_sndtimeo = 30 * HZ;
>> > server->ssocket = socket;
>> >
>> > return rc;
>> > diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
>> > index 2d1bd28..e4bf0b4 100644
>> > --- a/fs/cifs/transport.c
>> > +++ b/fs/cifs/transport.c
>> > @@ -197,6 +197,18 @@ smb_send2(struct TCP_Server_Info *server, struct kvec *iov, int n_vec)
>> > while (total_len) {
>> > rc = kernel_sendmsg(ssocket, &smb_msg, &iov[first_vec],
>> > n_vec - first_vec, total_len);
>> > +
>> > + /*
>> > + * blocking send -- just update total_len and break out of
>> > + * the loop. No sense in retrying since we've already given
>> > + * it a long timeout.
>> > + */
>> > + if (!server->noblocksnd) {
>> > + if (rc >= 0)
>> > + total_len -= rc;
>> > + break;
>> > + }
>> > +
>> > if ((rc == -ENOSPC) || (rc == -EAGAIN)) {
>> > i++;
>> > if (i >= 14) {
>> > --
>> > 1.5.5.1
>> >
>> >
>>
>>
>>
>> --
>> Thanks,
>>
>> Steve
>
>
> --
> Jeff Layton <jlayton at redhat.com>
>
--
Thanks,
Steve
More information about the linux-cifs-client
mailing list