1. 11 Jan, 2011 2 commits
    • J. Bruce Fields's avatar
      rpc: allow xprt_class->setup to return a preexisting xprt · f0418aa4
      J. Bruce Fields authored
      
      
      This allows us to reuse the xprt associated with a server connection if
      one has already been set up.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      f0418aa4
    • J. Bruce Fields's avatar
      rpc: keep backchannel xprt as long as server connection · 99de8ea9
      J. Bruce Fields authored
      
      
      Multiple backchannels can share the same tcp connection; from rfc 5661 section
      2.10.3.1:
      
      	A connection's association with a session is not exclusive.  A
      	connection associated with the channel(s) of one session may be
      	simultaneously associated with the channel(s) of other sessions
      	including sessions associated with other client IDs.
      
      However, multiple backchannels share a connection, they must all share
      the same xid stream (hence the same rpc_xprt); the only way we have to
      match replies with calls at the rpc layer is using the xid.
      
      So, keep the rpc_xprt around as long as the connection lasts, in case
      we're asked to use the connection as a backchannel again.
      
      Requests to create new backchannel clients over a given server
      connection should results in creating new clients that reuse the
      existing rpc_xprt.
      
      But to start, just reject attempts to associate multiple rpc_xprt's with
      the same underlying bc_xprt.
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      99de8ea9
  2. 19 Oct, 2010 2 commits
  3. 01 Oct, 2010 3 commits
  4. 04 Aug, 2010 2 commits
  5. 25 May, 2010 1 commit
  6. 18 May, 2010 1 commit
  7. 14 May, 2010 6 commits
  8. 20 Apr, 2010 1 commit
  9. 22 Mar, 2010 1 commit
  10. 03 Dec, 2009 1 commit
  11. 11 Sep, 2009 1 commit
  12. 17 Jun, 2009 4 commits
  13. 02 May, 2009 1 commit
  14. 11 Mar, 2009 4 commits
  15. 07 Oct, 2008 1 commit
  16. 09 Jul, 2008 2 commits
    • Chuck Lever's avatar
      SUNRPC: Ensure all transports set rq_xtime consistently · b22602a6
      Chuck Lever authored
      
      
      The RPC client uses the rq_xtime field in each RPC request to determine the
      round-trip time of the request.  Currently, the rq_xtime field is
      initialized by each transport just before it starts enqueing a request to
      be sent.  However, transports do not handle initializing this value
      consistently; sometimes they don't initialize it at all.
      
      To make the measurement of request round-trip time consistent for all
      RPC client transport capabilities, pull rq_xtime initialization into the
      RPC client's generic transport logic.  Now all transports will get a
      standardized RTT measure automatically, from:
      
        xprt_transmit()
      
      to
      
        xprt_complete_rqst()
      
      This makes round-trip time calculation more accurate for the TCP transport.
      The socket ->sendmsg() method can return "-EAGAIN" if the socket's output
      buffer is full, so the TCP transport's ->send_request() method may call
      the ->sendmsg() method repeatedly until it gets all of the request's bytes
      queued in the socket's buffer.
      
      Currently, the TCP transport sets the rq_xtime field every time through
      that loop so the final value is the timestamp just before the *last* call
      to the underlying socket's ->sendmsg() method.  After this patch, the
      rq_xtime field contains a timestamp that reflects the time just before the
      *first* call to ->sendmsg().
      
      This is consequential under heavy workloads because large requests often
      take multiple ->sendmsg() calls to get all the bytes of a request queued.
      The TCP transport causes the request to sleep until the remote end of the
      socket has received enough bytes to clear space in the socket's local
      output buffer.  This delay can be quite significant.
      
      The method introduced by this patch is a more accurate measure of RTT
      for stream transports, since the server can cause enough back pressure
      to delay (ie increase the latency of) requests from the client.
      
      Additionally, this patch corrects the behavior of the RDMA transport, which
      entirely neglected to initialize the rq_xtime field.  RPC performance
      metrics for RDMA transports now display correct RPC request round trip
      times.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Acked-by: default avatarTom Talpey <thomas.talpey@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      b22602a6
    • Chuck Lever's avatar
      SUNRPC: Remove obsolete messages during transport connect · cd983ef8
      Chuck Lever authored
      
      
      Recent changes to the RPC client's transport connect logic make connect
      status values ECONNREFUSED and ECONNRESET impossible.
      
      Clean up xprt_connect_status() to account for these changes.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      cd983ef8
  17. 27 Apr, 2008 1 commit
  18. 19 Apr, 2008 4 commits
    • Trond Myklebust's avatar
      SUNRPC: Don't disconnect more than once if retransmitting NFSv4 requests · 7c1d71cf
      Trond Myklebust authored
      
      
      NFSv4 requires us to ensure that we break the TCP connection before we're
      allowed to retransmit a request. However in the case where we're
      retransmitting several requests that have been sent on the same
      connection, we need to ensure that we don't interfere with the attempt to
      reconnect and/or break the connection again once it has been established.
      
      We therefore introduce a 'connection' cookie that is bumped every time a
      connection is broken. This allows requests to track if they need to force a
      disconnection.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      7c1d71cf
    • Trond Myklebust's avatar
    • Trond Myklebust's avatar
      SUNRPC: Fix read ordering problems with req->rq_private_buf.len · 1e799b67
      Trond Myklebust authored
      
      
      We want to ensure that req->rq_private_buf.len is updated before
      req->rq_received, so that call_decode() doesn't use an old value for
      req->rq_rcv_buf.len.
      
      In 'call_decode()' itself, instead of using task->tk_status (which is set
      using req->rq_received) must use the actual value of
      req->rq_private_buf.len when deciding whether or not the received RPC reply
      is too short.
      
      Finally ensure that we set req->rq_rcv_buf.len to zero when retrying a
      request. A typo meant that we were resetting req->rq_private_buf.len in
      call_decode(), and then clobbering that value with the old rq_rcv_buf.len
      again in xprt_transmit().
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      1e799b67
    • Trond Myklebust's avatar
      SUNRPC: Fix up xprt_write_space() · b6ddf64f
      Trond Myklebust authored
      
      
      The rest of the networking layer uses SOCK_ASYNC_NOSPACE to signal whether
      or not we have someone waiting for buffer memory. Convert the SUNRPC layer
      to use the same idiom.
      Remove the unlikely()s in xs_udp_write_space and xs_tcp_write_space. In
      fact, the most common case will be that there is nobody waiting for buffer
      space.
      
      SOCK_NOSPACE is there to tell the TCP layer whether or not the cwnd was
      limited by the application window. Ensure that we follow the same idiom as
      the rest of the networking layer here too.
      
      Finally, ensure that we clear SOCK_ASYNC_NOSPACE once we wake up, so that
      write_space() doesn't keep waking things up on xprt->pending.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      b6ddf64f
  19. 29 Feb, 2008 1 commit
  20. 25 Feb, 2008 1 commit
    • Trond Myklebust's avatar
      SUNRPC: Run rpc timeout functions as callbacks instead of in softirqs · 5d00837b
      Trond Myklebust authored
      
      
      An audit of the current RPC timeout functions shows that they don't really
      ever need to run in the softirq context. As long as the softirq is
      able to signal that the wakeup is due to a timeout (which it can do by
      setting task->tk_status to -ETIMEDOUT) then the callback functions can just
      run as standard task->tk_callback functions (in the rpciod/process
      context).
      
      The only possible border-line case would be xprt_timer() for the case of
      UDP, when the callback is used to reduce the size of the transport
      congestion window. In testing, however, the effect of moving that update
      to a callback would appear to be minor.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      5d00837b