Re: Sunrpc transport reconnection...

[Chuck Lever <chuck.lever@oracle.com>]

On 03/29/2010 05:43 PM, Trond Myklebust wrote:
> Having looked more carefully at the code...
>
> Is there any reason to keep the xprt->connect_timeout? As far as I can
> see, it would appear to be completely redundant.
>
> For UDP there is no disconnect/reconnect. The socket is set up once and
> for all, so no need for connect_timeout.

I vaguely recall at least one case where UDP connect can hang.  The 
connect_timeout in that case is short, on the order of 5 seconds.

> In the case of a TCP reconnection, the xprt->reestablish_timeout will do
> exponential back-off to prevent reconnecting unnecessarily. The
> XPRT_CONNECTING lock then prevents anyone from trying to interfere with
> that connect request until it gets a reply, or the TCP layer decides
> that the socket has timed out. Again, it appears that
> xprt->connect_timeout is redundant.

It probably is redundant when the host is unreachable.  We already have 
the retransmit timeout, and the socket connect call is always 
nonblocking because we aren't supposed to sleep.

If the server refuses our connection, the connect_timeout timer appears 
to be discarded, which is probably the wrong thing to do.

> RDMA reconnection appears to follow the TCP model. Once again, there is
> exponential back-off, enforced by XPRT_CONNECTING.
>
> So why do we have xprt->connect_timeout? What is it enforcing?

It may be a vestige of the previous connect implementation, where 
call_connect actually could have slept in the RPC scheduler.

We eventually want to invoke call_timeout if the connection never 
completes.  It could be because the server keeps refusing or resetting 
our connection, or because there is no response from the server.  The 
retransmit timeout is probably appropriate for both of those cases.

-- 
chuck[dot]lever[at]oracle[dot]com