1. 07 9月, 2012 1 次提交
    • T
      SUNRPC: Fix a UDP transport regression · f39c1bfb
      Trond Myklebust 提交于
      Commit 43cedbf0 (SUNRPC: Ensure that
      we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
      hangs in the case of NFS over UDP mounts.
      
      Since neither the UDP or the RDMA transport mechanism use dynamic slot
      allocation, we can skip grabbing the socket lock for those transports.
      Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
      case.
      
      Note that the NFSv4.1 back channel assigns the slot directly
      through rpc_run_bc_task, so we can ignore that case.
      Reported-by: NDick Streefland <dick.streefland@altium.nl>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org [>= 3.1]
      f39c1bfb
  2. 11 7月, 2012 1 次提交
  3. 20 5月, 2012 1 次提交
  4. 17 5月, 2012 1 次提交
  5. 16 4月, 2012 1 次提交
  6. 03 3月, 2012 1 次提交
  7. 18 2月, 2012 1 次提交
  8. 17 2月, 2012 1 次提交
    • A
      SUNRPC: add sending,pending queue and max slot to xprt stats · 15a45206
      Andy Adamson 提交于
      With static RPC slots, the xprt backlog queue stats were useful in showing
      when the transport (TCP) was starved by lack of RPC slots. The new dynamic
      RPC slot code, commit d9ba131d, always
      provides an RPC slot and so only uses the xprt backlog queue when the
      tcp_max_slot_table_entries value has been hit or when an allocation error
      occurs. All requests are now placed on the xprt sending or pending queue which
      need to be monitored for debugging.
      
      The max_slot stat shows the maximum number of dynamic RPC slots reached which is
      useful when debugging performance issues.
      
      Add the new fields at the end of the mountstats xprt stanza so that mountstats
      outputs the previous correct values and ignores the new fields. Bump
      NFS_IOSTATS_VERS.
      Signed-off-by: NAndy Adamson <andros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      15a45206
  9. 07 2月, 2012 1 次提交
  10. 01 2月, 2012 1 次提交
  11. 02 12月, 2011 1 次提交
  12. 29 7月, 2011 1 次提交
  13. 18 7月, 2011 5 次提交
  14. 15 7月, 2011 1 次提交
  15. 19 4月, 2011 1 次提交
  16. 18 3月, 2011 2 次提交
  17. 16 3月, 2011 1 次提交
  18. 12 1月, 2011 2 次提交
    • J
      rpc: allow xprt_class->setup to return a preexisting xprt · f0418aa4
      J. Bruce Fields 提交于
      This allows us to reuse the xprt associated with a server connection if
      one has already been set up.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      f0418aa4
    • J
      rpc: keep backchannel xprt as long as server connection · 99de8ea9
      J. Bruce Fields 提交于
      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: NJ. Bruce Fields <bfields@redhat.com>
      99de8ea9
  19. 19 10月, 2010 2 次提交
  20. 02 10月, 2010 3 次提交
  21. 04 8月, 2010 2 次提交
  22. 25 5月, 2010 1 次提交
  23. 18 5月, 2010 1 次提交
  24. 15 5月, 2010 6 次提交
  25. 21 4月, 2010 1 次提交