On May 21, 2014, at 10:07 PM, Trond Myklebust <trondmy@xxxxxxxxx> wrote: > On Wed, May 21, 2014 at 8:57 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> If the new connection is able to make forward progress, reset the >> re-establish timeout. Otherwise it keeps growing even if disconnect >> events are rare. >> >> The same behavior as TCP is adopted: reconnect immediately if the >> transport instance has been able to make some forward progress. >> >> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx> >> --- >> >> net/sunrpc/xprtrdma/rpc_rdma.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c >> index dc4a826..1334646 100644 >> --- a/net/sunrpc/xprtrdma/rpc_rdma.c >> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c >> @@ -770,6 +770,8 @@ repost: >> >> /* from here on, the reply is no longer an orphan */ >> req->rl_reply = rep; >> + if (xprt->reestablish_timeout) >> + xprt->reestablish_timeout = 0; > > What's the point of making this conditional? Good catch. I’ll remove the conditional. I copied this straight from xs_tcp_data_ready(). -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
