1. 08 7月, 2012 3 次提交
    • H
      {NET, IB}/mlx4: Add device managed flow steering firmware API · 0ff1fb65
      Hadar Hen Zion 提交于
      The driver is modified to support three operation modes.
      
      If supported by firmware use the device managed flow steering
      API, that which we call device managed steering mode. Else, if
      the firmware supports the B0 steering mode use it, and finally,
      if none of the above, use the A0 steering mode.
      
      When the steering mode is device managed, the code is modified
      such that L2 based rules set by the mlx4_en driver for Ethernet
      unicast and multicast, and the IB stack multicast attach calls
      done through the mlx4_ib driver are all routed to use the device
      managed API.
      
      When attaching rule using device managed flow steering API,
      the firmware returns a 64 bit registration id, which is to be
      provided during detach.
      
      Currently the firmware is always programmed during HCA initialization
      to use standard L2 hashing. Future work should be done to allow
      configuring the flow-steering hash function with common, non
      proprietary means.
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ff1fb65
    • H
      net/mlx4_core: Add firmware commands to support device managed flow steering · 8fcfb4db
      Hadar Hen Zion 提交于
      Add support for firmware commands to attach/detach a new device managed
      steering mode. Such network steering rules allow the user to provide an
      L2/L3/L4 flow specification to the firmware and have the device to steer
      traffic that matches that specification to the provided QP.
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8fcfb4db
    • H
      net/mlx4: Set steering mode according to device capabilities · c96d97f4
      Hadar Hen Zion 提交于
      Instead of checking the firmware supported steering mode in various
      places in the code, add a dedicated field in the mlx4 device capabilities
      structure which is written once during the initialization flow and read
      across the code.
      
      This also set the grounds for add new steering modes. Currently two modes
      are supported, and are named after the ConnectX HW versions A0 and B0.
      
      A0 steering uses mac_index, vlan_index and priority to steer traffic
      into pre-defined range of QPs.
      
      B0 steering uses Ethernet L2 hashing rules and is enabled only
      if the firmware supports both unicast and multicast B0 steering,
      
      The current steering modes are relevant for Ethernet traffic only,
      such that Infiniband steering remains untouched.
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c96d97f4
  2. 01 6月, 2012 1 次提交
    • M
      net/mlx4_core: Fix number of EQs used in ICM initialisation · 3fc929e2
      Marcel Apfelbaum 提交于
      In SRIOV mode, the number of EQs used when computing the total ICM size
      was incorrect.
      
      To fix this, we do the following:
      1. We add a new structure to mlx4_dev, mlx4_phys_caps, to contain physical HCA
         capabilities.  The PPF uses the phys capabilities when it computes things
         like ICM size.
      
         The dev_caps structure will then contain the paravirtualized values, making
         bookkeeping much easier in SRIOV mode. We add a structure rather than a
         single parameter because there will be other fields in the phys_caps.
      
         The first field we add to the mlx4_phys_caps structure is num_phys_eqs.
      
      2. In INIT_HCA, when running in SRIOV mode, the "log_num_eqs" parameter
         passed to the FW is the number of EQs per VF/PF; each function (PF or VF)
         has this number of EQs available.
      
         However, the total number of EQs which must be allowed for in the ICM is
         (1 << log_num_eqs) * (#VFs + #PFs).  Rather than compute this quantity,
         we allocate ICM space for 1024 EQs (which is the device maximum
         number of EQs, and which is the value we place in the mlx4_phys_caps structure).
      
         For INIT_HCA, however, we use the per-function number of EQs as described
         above.
      Signed-off-by: NMarcel Apfelbaum <marcela@dev.mellanox.co.il>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3fc929e2
  3. 09 5月, 2012 2 次提交
  4. 05 4月, 2012 2 次提交
    • A
      net/mlx4_core: set port QoS attributes · e5395e92
      Amir Vadai 提交于
      Adding QoS firmware commands:
      - mlx4_en_SET_PORT_PRIO2TC - set UP <=> TC
      - mlx4_en_SET_PORT_SCHEDULER - set promised BW, max BW and PG number
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5395e92
    • A
      net/mlx4_en: Force user priority by QP attribute · 0e98b523
      Amir Vadai 提交于
      Instead of relying on HW to change schedule queue by UP, schedule
      queue is fixed for a tx_ring, and UP in WQE is ignored in this aspect.  This
      resolves two issues with untagged traffic:
      1. untagged traffic has no UP in packet which is needed for QoS. The change
         above allows setting the schedule queue (and by that the UP) of such a stream.
      2. BlueFlame uses the same field used by vlan tag. So forcing UP from QPC
         allows using BF for untagged but prioritized traffic.
      
      In old firmware that force UP is not supported, untagged traffic will not subject to
      QoS.
      
      Because UP is set by QP, need to always have a tx ring per UP, even if pfcrx
      module paramter is false.
      Signed-off-by: NAmir Vadai <amirv@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e98b523
  5. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  6. 13 3月, 2012 2 次提交
  7. 07 3月, 2012 2 次提交
  8. 27 2月, 2012 1 次提交
  9. 26 2月, 2012 1 次提交
  10. 23 1月, 2012 1 次提交
  11. 20 12月, 2011 2 次提交
  12. 14 12月, 2011 7 次提交
  13. 28 11月, 2011 3 次提交
  14. 29 10月, 2011 1 次提交
  15. 19 10月, 2011 1 次提交
  16. 14 10月, 2011 3 次提交
  17. 27 7月, 2011 1 次提交
  18. 19 7月, 2011 5 次提交
  19. 24 3月, 2011 1 次提交