1. 11 11月, 2014 1 次提交
  2. 14 10月, 2014 3 次提交
  3. 22 7月, 2014 1 次提交
  4. 16 7月, 2014 1 次提交
    • H
      cxgb4/iw_cxgb4: use firmware ord/ird resource limits · 4c2c5763
      Hariprasad Shenai 提交于
      Advertise a larger max read queue depth for qps, and gather the resource limits
      from fw and use them to avoid exhaustinq all the resources.
      
      Design:
      
      cxgb4:
      
      Obtain the max_ordird_qp and max_ird_adapter device params from FW
      at init time and pass them up to the ULDs when they attach.  If these
      parameters are not available, due to older firmware, then hard-code
      the values based on the known values for older firmware.
      iw_cxgb4:
      
      Fix the c4iw_query_device() to report these correct values based on
      adapter parameters.  ibv_query_device() will always return:
      
      max_qp_rd_atom = max_qp_init_rd_atom = min(module_max, max_ordird_qp)
      max_res_rd_atom = max_ird_adapter
      
      Bump up the per qp max module option to 32, allowing it to be increased
      by the user up to the device max of max_ordird_qp.  32 seems to be
      sufficient to maximize throughput for streaming read benchmarks.
      
      Fail connection setup if the negotiated IRD exhausts the available
      adapter ird resources.  So the driver will track the amount of ird
      resource in use and not send an RI_WR/INIT to FW that would reduce the
      available ird resources below zero.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c2c5763
  5. 14 7月, 2014 1 次提交
  6. 09 7月, 2014 2 次提交
  7. 02 7月, 2014 1 次提交
  8. 11 6月, 2014 3 次提交
  9. 20 5月, 2014 1 次提交
  10. 29 4月, 2014 2 次提交
    • S
      RDMA/cxgb4: Force T5 connections to use TAHOE congestion control · 92e5011a
      Steve Wise 提交于
      This is required to work around a T5 HW issue.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      92e5011a
    • S
      RDMA/cxgb4: Fix endpoint mutex deadlocks · cc18b939
      Steve Wise 提交于
      In cases where the cm calls c4iw_modify_rc_qp() with the endpoint
      mutex held, they must be called with internal == 1.  rx_data() and
      process_mpa_reply() are not doing this.  This causes a deadlock
      because c4iw_modify_rc_qp() might call c4iw_ep_disconnect() in some
      !internal cases, and c4iw_ep_disconnect() acquires the endpoint mutex.
      The design was intended to only do the disconnect for !internal calls.
      
      Change rx_data(), FPDU_MODE case, to call c4iw_modify_rc_qp() with
      internal == 1, and then disconnect only after releasing the mutex.
      
      Change process_mpa_reply() to call c4iw_modify_rc_qp(TERMINATE) with
      internal == 1 and set a new attr flag telling it to send a TERMINATE
      message.  Previously this was implied by !internal.
      
      Change process_mpa_reply() to return whether the caller should
      disconnect after releasing the endpoint mutex.  Now rx_data() will do
      the disconnect in the cases where process_mpa_reply() wants to
      disconnect after the TERMINATE is sent.
      
      Change c4iw_modify_rc_qp() RTS->TERM to only disconnect if !internal,
      and to send a TERMINATE message if attrs->send_term is 1.
      
      Change abort_connection() to not aquire the ep mutex for setting the
      state, and make all calls to abort_connection() do so with the mutex
      held.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      cc18b939
  11. 12 4月, 2014 1 次提交
    • S
      RDMA/cxgb4: Endpoint timeout fixes · b33bd0cb
      Steve Wise 提交于
      1) timedout endpoint processing can be starved. If there are continual
         CPL messages flowing into the driver, the endpoint timeout
         processing can be starved.  This condition exposed the other bugs
         below.
      
      Solution: In process_work(), call process_timedout_eps() after each CPL
      is processed.
      
      2) Connection events can be processed even though the endpoint is on
         the timeout list.  If the endpoint is scheduled for timeout
         processing, then we must ignore MPA Start Requests and Replies.
      
      Solution: Change stop_ep_timer() to return 1 if the ep has already been
      queued for timeout processing.  All the callers of stop_ep_timer() need
      to check this and act accordingly.  There are just a few cases where
      the caller needs to do something different if stop_ep_timer() returns 1:
      
      1) in process_mpa_reply(), ignore the reply and  process_timeout()
         will abort the connection.
      
      2) in process_mpa_request, ignore the request and process_timeout()
         will abort the connection.
      
      It is ok for callers of stop_ep_timer() to abort the connection since
      that will leave the state in ABORTING or DEAD, and process_timeout()
      now ignores timeouts when the ep is in these states.
      
      3) Double insertion on the timeout list.  Since the endpoint timers
         are used for connection setup and teardown, we need to guard
         against the possibility that an endpoint is already on the timeout
         list.  This is a rare condition and only seen under heavy load and
         in the presense of the above 2 bugs.
      
      Solution: In ep_timeout(), don't queue the endpoint if it is already on
      the queue.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      b33bd0cb
  12. 02 4月, 2014 3 次提交
  13. 25 3月, 2014 3 次提交
  14. 21 3月, 2014 3 次提交
  15. 15 3月, 2014 1 次提交
  16. 14 2月, 2014 1 次提交
  17. 23 12月, 2013 3 次提交
  18. 14 8月, 2013 4 次提交
  19. 13 8月, 2013 1 次提交
  20. 18 3月, 2013 1 次提交
    • C
      tcp: Remove TCPCT · 1a2c6181
      Christoph Paasch 提交于
      TCPCT uses option-number 253, reserved for experimental use and should
      not be used in production environments.
      Further, TCPCT does not fully implement RFC 6013.
      
      As a nice side-effect, removing TCPCT increases TCP's performance for
      very short flows:
      
      Doing an apache-benchmark with -c 100 -n 100000, sending HTTP-requests
      for files of 1KB size.
      
      before this patch:
      	average (among 7 runs) of 20845.5 Requests/Second
      after:
      	average (among 7 runs) of 21403.6 Requests/Second
      Signed-off-by: NChristoph Paasch <christoph.paasch@uclouvain.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1a2c6181
  21. 15 3月, 2013 1 次提交
  22. 14 3月, 2013 2 次提交