On Wed, 2008-10-08 at 13:51 -0400, Talpey, Thomas wrote: > At 01:35 PM 10/8/2008, Trond Myklebust wrote: > >Hmm... Why not rather do the same as the socket code: have the > >disconnect handler paths that don't require exponential backoff just > >reset xprt->reestablish_timeout to 0? > > Because we do want a non-zero reestablishment timeout in general, and > the RDMA client has not implemented a connection backoff. So in effect > the value is constant for this code, and I thought treating it as such is > the safer fix. > > I'm not 100% convinced the TCP code is correct, btw. It appears to > zero out the reestablish timeout on idle-disconnect, but it's not obvious > to me where it sets it back to a non-zero value. It does try to double > it in xs_connect() though! :-) The TCP code sets the xprt->reestablish_timeout to a non-zero value whenever the _server_ closes the connection (i.e. if ever we enter a SYN_SENT state followed by a reset, a CLOSE_WAIT state or a CLOSING state. Why would the RDMA client want to do anything different? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
