1. 24 10月, 2019 3 次提交
    • C
      xprtrdma: Close window between waking RPC senders and posting Receives · 2ae50ad6
      Chuck Lever 提交于
      A recent clean up attempted to separate Receive handling and RPC
      Reply processing, in the name of clean layering.
      
      Unfortunately, we can't do this because the Receive Queue has to be
      refilled _after_ the most recent credit update from the responder
      is parsed from the transport header, but _before_ we wake up the
      next RPC sender. That is right in the middle of
      rpcrdma_reply_handler().
      
      Usually this isn't a problem because current responder
      implementations don't vary their credit grant. The one exception is
      when a connection is established: the grant goes from one to a much
      larger number on the first Receive. The requester MUST post enough
      Receives right then so that any outstanding requests can be sent
      without risking RNR and connection loss.
      
      Fixes: 6ceea368 ("xprtrdma: Refactor Receive accounting")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      2ae50ad6
    • C
      xprtrdma: Initialize rb_credits in one place · eea63ca7
      Chuck Lever 提交于
      Clean up/code de-duplication.
      
      Nit: RPC_CWNDSHIFT is incorrect as the initial value for xprt->cwnd.
      This mistake does not appear to have operational consequences, since
      the cwnd value is replaced with a valid value upon the first Receive
      completion.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      eea63ca7
    • C
      xprtrdma: Connection becomes unstable after a reconnect · a31b2f93
      Chuck Lever 提交于
      This is because xprt_request_get_cong() is allowing more than one
      RPC Call to be transmitted before the first Receive on the new
      connection. The first Receive fills the Receive Queue based on the
      server's credit grant. Before that Receive, there is only a single
      Receive WR posted because the client doesn't know the server's
      credit grant.
      
      Solution is to clear rq_cong on all outstanding rpc_rqsts when the
      the cwnd is reset. This is because an RPC/RDMA credit is good for
      one connection instance only.
      
      Fixes: 75891f50 ("SUNRPC: Support for congestion control ... ")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a31b2f93
  2. 27 8月, 2019 2 次提交
  3. 22 8月, 2019 1 次提交
  4. 21 8月, 2019 9 次提交
  5. 20 8月, 2019 1 次提交
    • C
      xprtrdma: Boost maximum transport header size · f3c66a2f
      Chuck Lever 提交于
      Although I haven't seen any performance results that justify it,
      I've received several complaints that NFS/RDMA no longer supports
      a maximum rsize and wsize of 1MB. These days it is somewhat smaller.
      
      To simplify the logic that determines whether a chunk list is
      necessary, the implementation uses a fixed maximum size of the
      transport header. Currently that maximum size is 256 bytes, one
      quarter of the default inline threshold size for RPC/RDMA v1.
      
      Since commit a7886849 ("xprtrdma: Reduce max_frwr_depth"), the
      size of chunks is also smaller to take advantage of inline page
      lists in device internal MR data structures.
      
      The combination of these two design choices has reduced the maximum
      NFS rsize and wsize that can be used for most RNIC/HCAs. Increasing
      the maximum transport header size and the maximum number of RDMA
      segments it can contain increases the negotiated maximum rsize/wsize
      on common RNIC/HCAs.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      f3c66a2f
  6. 05 8月, 2019 1 次提交
  7. 09 7月, 2019 6 次提交
  8. 03 7月, 2019 1 次提交
  9. 28 5月, 2019 1 次提交
  10. 26 4月, 2019 13 次提交
  11. 12 4月, 2019 1 次提交
  12. 13 2月, 2019 1 次提交