1. 19 8月, 2016 1 次提交
  2. 26 7月, 2016 1 次提交
  3. 27 4月, 2016 1 次提交
  4. 22 3月, 2016 1 次提交
  5. 01 3月, 2016 1 次提交
    • H
      cxgb4/iw_cxgb4: TOS support · ac8e4c69
      Hariprasad S 提交于
      This series provides support for iWARP applications to specify a TOS
      value and have that map to a VLAN Priority for iw_cxgb4 iWARP connections.
      
      In iw_cxgb4, when allocating an L2T entry, pass the skb_priority based
      on the tos value in the cm_id. Also pass the correct tos value during
      connection setup so the passive side gets the client's desired tos.
      When sending the FLOWC work request to FW, if the egress device is
      in a vlan, then use the vlan priority bits as the scheduling class.
      This allows associating RDMA connections with scheduling classes to
      provide traffic shaping per flow.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      ac8e4c69
  6. 11 2月, 2016 1 次提交
    • H
      cxgb4/iw_cxgb4: TOS support · ba9cee6a
      Hariprasad Shenai 提交于
      This series provides support for iWARP applications to specify a TOS
      value and have that map to a VLAN Priority for iw_cxgb4 iWARP connections.
      
      In iw_cxgb4, when allocating an L2T entry, pass the skb_priority based
      on the tos value in the cm_id. Also pass the correct tos value during
      connection setup so the passive side gets the client's desired tos.
      When sending the FLOWC work request to FW, if the egress device is
      in a vlan, then use the vlan priority bits as the scheduling class.
      This allows associating RDMA connections with scheduling classes to
      provide traffic shaping per flow.
      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>
      ba9cee6a
  7. 10 9月, 2015 1 次提交
  8. 06 6月, 2015 1 次提交
  9. 02 6月, 2015 1 次提交
  10. 25 5月, 2015 1 次提交
  11. 13 5月, 2015 1 次提交
  12. 06 5月, 2015 2 次提交
  13. 02 4月, 2015 1 次提交
  14. 09 3月, 2015 1 次提交
  15. 10 2月, 2015 1 次提交
  16. 08 2月, 2015 1 次提交
  17. 25 1月, 2015 1 次提交
  18. 09 1月, 2015 1 次提交
  19. 19 12月, 2014 1 次提交
  20. 13 12月, 2014 2 次提交
  21. 23 11月, 2014 5 次提交
  22. 14 11月, 2014 1 次提交
  23. 11 11月, 2014 1 次提交
  24. 02 9月, 2014 1 次提交
  25. 22 8月, 2014 1 次提交
  26. 08 8月, 2014 1 次提交
    • A
      cxgb4: IEEE fixes for DCBx state machine · 10b00466
      Anish Bhatt 提交于
      * Changes required due to 16eecd9b ("dcbnl : Fix misleading
        dcb_app->priority explanation")
      * Driver was previously not aware of what DCBx version was negotiated by
        firmware, this could lead to DCB app table  in kernel or in firmware being
        populated wrong  since IEEE/CEE used different formats made clear by above
        mentioned commit
      * Driver was missing a couple of state transitions that could be caused
        by other drivers that use chelsio hardware, resulting in incorrect behaviour
        (the change that addresses this also flips the state machine to switch on
         state instead of transition, hope this is okay in current window)
      * Prio queue info & tsa is no longer thrown away
      
      v2: Print DCBx state transition messages only when debug is enabled
      Signed-off-by: NAnish Bhatt <anish@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10b00466
  27. 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
  28. 23 6月, 2014 2 次提交
  29. 19 2月, 2014 2 次提交
  30. 04 12月, 2013 1 次提交
  31. 13 8月, 2013 1 次提交
  32. 30 4月, 2013 1 次提交
    • V
      cxgb4: Support CPL_SGE_EGR_UPDATEs encapsulated in a CPL_FW4_MSG · b407a4a9
      Vipul Pandya 提交于
      Newer firmware can post CPL_SGE_EGR_UPDATE message encapsulated in a
      CPL_FW4_MSG as follows
      
      flit0 rss_header (if DropRSS == 0 in IQ context)
      flit1 CPL_FW4_MSG cpl
      flit2 rss_header w/opcode CPL_SGE_EGR_UPDATE
      flit3 CPL_SGE_EGR_UPDATE cpl
      
      So FW4_MSG CPLs with a newly created type of FW_TYPE_RSSCPL have the
      CPL_SGE_EGR_UPDATE CPL message in flit 2 of the FW4_MSG. Firmware can still
      post regular CPL_SGE_EGR_UPDATE messages, so the drivers need to handle
      both.
      
      This patch also writes a new parameter to firmware requesting encapsulated
      EGR_UPDATE. This allows firmware with this support to not break older drivers.
      Signed-off-by: NVipul Pandya <vipul@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b407a4a9