| Message ID | 20140522005707.27190.2035.stgit@manet.1015granger.net (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Wed, May 21, 2014 at 8:57 PM, Chuck Lever <chuck.lever@oracle.com> 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@oracle.com> > --- > > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 21, 2014, at 10:07 PM, Trond Myklebust <trondmy@gmail.com> wrote: > On Wed, May 21, 2014 at 8:57 PM, Chuck Lever <chuck.lever@oracle.com> 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@oracle.com> >> --- >> >> 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-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; /* check for expected message types */ /* The order of some of these tests is important. */
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@oracle.com> --- net/sunrpc/xprtrdma/rpc_rdma.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html