1. 26 1月, 2015 3 次提交
  2. 31 12月, 2014 1 次提交
  3. 12 12月, 2014 4 次提交
    • M
      net/mlx4: Add support for A0 steering · 7d077cd3
      Matan Barak 提交于
      Add the required firmware commands for A0 steering and a way to enable
      that. The firmware support focuses on INIT_HCA, QUERY_HCA, QUERY_PORT,
      QUERY_DEV_CAP and QUERY_FUNC_CAP commands. Those commands are used
      to configure and query the device.
      
      The different A0 DMFS (steering) modes are:
      
      Static - optimized performance, but flow steering rules are
      limited. This mode should be choosed explicitly by the user
      in order to be used.
      
      Dynamic - this mode should be explicitly choosed by the user.
      In this mode, the FW works in optimized steering mode as long as
      it can and afterwards automatically drops to classic (full) DMFS.
      
      Disable - this mode should be explicitly choosed by the user.
      The user instructs the system not to use optimized steering, even if
      the FW supports Dynamic A0 DMFS (and thus will be able to use optimized
      steering in Default A0 DMFS mode).
      
      Default - this mode is implicitly choosed. In this mode, if the FW
      supports Dynamic A0 DMFS, it'll work in this mode. Otherwise, it'll
      work at Disable A0 DMFS mode.
      
      Under SRIOV configuration, when the A0 steering mode is enabled,
      older guest VF drivers who aren't using the RX QP allocation flag
      (MLX4_RESERVE_A0_QP) will get a QP from the general range and
      fail when attempting to register a steering rule. To avoid that,
      the PF context behaviour is changed once on A0 static mode, to
      require support for the allocation flag in VF drivers too.
      
      In order to enable A0 steering, we use log_num_mgm_entry_size param.
      If the value of the parameter is not positive, we treat the absolute
      value of log_num_mgm_entry_size as a bit field. Setting bit 2 of this
      bit field enables static A0 steering.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d077cd3
    • M
      net/mlx4: Add A0 hybrid steering · d57febe1
      Matan Barak 提交于
      A0 hybrid steering is a form of high performance flow steering.
      By using this mode, mlx4 cards use a fast limited table based steering,
      in order to enable fast steering of unicast packets to a QP.
      
      In order to implement A0 hybrid steering we allocate resources
      from different zones:
      (1) General range
      (2) Special MAC-assigned QPs [RSS, Raw-Ethernet] each has its own region.
      
      When we create a rss QP or a raw ethernet (A0 steerable and BF ready) QP,
      we try hard to allocate the QP from range (2). Otherwise, we try hard not
      to allocate from this  range. However, when the system is pushed to its
      limits and one needs every resource, the allocator uses every region it can.
      
      Meaning, when we run out of raw-eth qps, the allocator allocates from the
      general range (and the special-A0 area is no longer active). If we run out
      of RSS qps, the mechanism tries to allocate from the raw-eth QP zone. If that
      is also exhausted, the allocator will allocate from the general range
      (and the A0 region is no longer active).
      
      Note that if a raw-eth qp is allocated from the general range, it attempts
      to allocate the range such that bits 6 and 7 (blueflame bits) in the
      QP number are not set.
      
      When the feature is used in SRIOV, the VF has to notify the PF what
      kind of QP attributes it needs. In order to do that, along with the
      "Eth QP blueflame" bit, we reserve a new "A0 steerable QP". According
      to the combination of these bits, the PF tries to allocate a suitable QP.
      
      In order to maintain backward compatibility (with older PFs), the PF
      notifies which QP attributes it supports via QUERY_FUNC_CAP command.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d57febe1
    • E
      net/mlx4: Change QP allocation scheme · ddae0349
      Eugenia Emantayev 提交于
      When using BF (Blue-Flame), the QPN overrides the VLAN, CV, and SV fields
      in the WQE. Thus, BF may only be used for QPNs with bits 6,7 unset.
      
      The current Ethernet driver code reserves a Tx QP range with 256b alignment.
      
      This is wrong because if there are more than 64 Tx QPs in use,
      QPNs >= base + 65 will have bits 6/7 set.
      
      This problem is not specific for the Ethernet driver, any entity that
      tries to reserve more than 64 BF-enabled QPs should fail. Also, using
      ranges is not necessary here and is wasteful.
      
      The new mechanism introduced here will support reservation for
      "Eth QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
      (when hypervisors support WC in VMs). The flow we use is:
      
      1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
         and request "BF enabled QPs" if BF is supported for the function
      
      2. In the ALLOC_RES FW command, change param1 to:
      a. param1[23:0]  - number of QPs
      b. param1[31-24] - flags controlling QPs reservation
      
      Bit 31 refers to Eth blueflame supported QPs. Those QPs must have
      bits 6 and 7 unset in order to be used in Ethernet.
      
      Bits 24-30 of the flags are currently reserved.
      
      When a function tries to allocate a QP, it states the required attributes
      for this QP. Those attributes are considered "best-effort". If an attribute,
      such as Ethernet BF enabled QP, is a must-have attribute, the function has
      to check that attribute is supported before trying to do the allocation.
      
      In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
      which are unsupported. If SRIOV is used, the PF validates those attributes
      and masks out unsupported attributes as well. In order to notify VFs which
      attributes are supported, the VF uses QUERY_FUNC_CAP command. This command's
      mailbox is filled by the PF, which notifies which QP allocation attributes
      it supports.
      Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddae0349
    • M
      net/mlx4_core: Use tasklet for user-space CQ completion events · 3dca0f42
      Matan Barak 提交于
      Previously, we've fired all our completion callbacks straight from our ISR.
      
      Some of those callbacks were lightweight (for example, mlx4_en's and
      IPoIB napi callbacks), but some of them did more work (for example,
      the user-space RDMA stack uverbs' completion handler). Besides that,
      doing more than the minimal work in ISR is generally considered wrong,
      it could even lead to a hard lockup of the system. Since when a lot
      of completion events are generated by the hardware, the loop over those
      events could be so long, that we'll get into a hard lockup by the system
      watchdog.
      
      In order to avoid that, add a new way of invoking completion events
      callbacks. In the interrupt itself, we add the CQs which receive completion
      event to a per-EQ list and schedule a tasklet. In the tasklet context
      we loop over all the CQs in the list and invoke the user callback.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dca0f42
  4. 14 11月, 2014 2 次提交
  5. 12 11月, 2014 1 次提交
  6. 04 11月, 2014 1 次提交
  7. 29 10月, 2014 3 次提交
  8. 06 10月, 2014 1 次提交
  9. 01 10月, 2014 1 次提交
    • M
      net/mlx4_core: New init and exit flow for mlx4_core · e1c00e10
      Majd Dibbiny 提交于
      In the new flow, we separate the pci initialization and teardown
      from the initialization and teardown of the other resources.
      
      __mlx4_init_one handles the pci resources initialization. It then
      calls mlx4_load_one to initialize the remainder of the resources.
      
      When removing a device, mlx4_remove_one is invoked. However, now
      mlx4_remove_one calls mlx4_unload_one to free all the resources except the pci
      resources. When mlx4_unload_one returns, mlx4_remove_one then frees the
      pci resources.
      
      The above separation will allow us to implement 'reset flow' in the future.
      It will also enable more EQs for VFs and is a pre-step to the modern API to
      enable/disable SRIOV.
      
      Also added nvfs; an integer array of size MLX4_MAX_PORTS + 1; to the mlx4_dev
      struct. This new field is used to avoid parsing the num_vfs module parameter
      each time the mlx4_restart_one is called.
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e1c00e10
  10. 20 9月, 2014 1 次提交
    • I
      net/mlx4_core: Enable CQE/EQE stride support · 77507aa2
      Ido Shamay 提交于
      This feature is intended for archs having cache line larger then 64B.
      
      Since our CQE/EQEs are generally 64B in those systems, HW will write
      twice to the same cache line consecutively, causing pipe locks due to
      he hazard prevention mechanism. For elements in a cyclic buffer, writes
      are consecutive, so entries smaller than a cache line should be
      avoided, especially if they are written at a high rate.
      
      Reduce consecutive writes to same cache line in CQs/EQs, by allowing the
      driver to increase the distance between entries so that each will reside
      in a different cache line. Until the introduction of this feature, there
      were two types of CQE/EQE:
      
      1. 32B stride and context in the [0-31] segment
      2. 64B stride and context in the [32-63] segment
      
      This feature introduces two additional types:
      
      3. 128B stride and context in the [0-31] segment (128B cache line)
      4. 256B stride and context in the [0-31] segment (256B cache line)
      
      Modify the mlx4_core driver to query the device for the CQE/EQE cache
      line stride capability and to enable that capability when the host
      cache line size is larger than 64 bytes (supported cache lines are
      128B and 256B).
      
      The mlx4 IB driver and libmlx4 need not be aware of this change. The PF
      context behaviour is changed to require this change in VF drivers
      running on such archs.
      Signed-off-by: NIdo Shamay <idos@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77507aa2
  11. 11 9月, 2014 1 次提交
  12. 30 8月, 2014 1 次提交
  13. 26 8月, 2014 1 次提交
  14. 05 8月, 2014 1 次提交
    • J
      mlx4_core: Add support for secure-host and SMP firewall · 114840c3
      Jack Morgenstein 提交于
      Secure-host is the general term for the capability of a device
      to protect itself and the subnet from malicious host software.
      
      This is achieved by:
      1. Not allowing un-trusted entities to access device configuration
         registers, directly (through pci_cr or pci_conf) and indirectly
         (through MADs).
      
      2. Hiding M_Key from untrusted entities.
      
      3. Preventing the modification of GUID0 by un-trusted entities
      
      4. Not allowing drivers on untrusted hosts to receive nor to transmit
         packets over QP0 (SMP Firewall).
      
      The secure-host capability depends on firmware handling all QP0
      packets, and not passing these packets up to the driver. Any information
      required by the driver for proper operation (e.g., SM lid) is passed
      via events generated by the firmware while processing QP0 MADs.
      
      Driver support mainly requires using the MAD_DEMUX FW command at startup,
      where the feature is enabled/disabled through a procedure described in
      the Mellanox HCA tools package.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      
      [ Fix error path in mlx4_setup_hca to go to err_mcg_table_free. - Roland ]
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      114840c3
  15. 02 8月, 2014 1 次提交
  16. 23 7月, 2014 1 次提交
  17. 09 7月, 2014 1 次提交
  18. 03 7月, 2014 1 次提交
  19. 03 6月, 2014 1 次提交
  20. 02 6月, 2014 2 次提交
  21. 30 5月, 2014 3 次提交
    • J
      IB/mlx4: Add interface for selecting VFs to enable QP0 via MLX proxy QPs · 65fed8a8
      Jack Morgenstein 提交于
      This commit adds the sysfs interface for enabling QP0 on VFs for
      selected VF/port.
      
      By default, no VFs are enabled for QP0 operation.
      
      To enable QP0 operation on a VF/port, under
      /sys/class/infiniband/mlx4_x/iov/<b:d:f>/ports/x there are two new entries:
      
      - smi_enabled (read-only). Indicates whether smi is currently
        enabled for the indicated VF/port
      
      - enable_smi_admin (rw). Used by the admin to request that smi
        capability be enabled or disabled for the indicated VF/port.
        0 = disable, 1 = enable.
        The requested enablement will occur at the next reset of the
        VF (e.g. driver restart on the VM which owns the VF).
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      65fed8a8
    • J
      mlx4: Add infrastructure for selecting VFs to enable QP0 via MLX proxy QPs · 99ec41d0
      Jack Morgenstein 提交于
      This commit adds the infrastructure for enabling selected VFs to
      operate SMI (QP0) MADs without restriction.
      
      Additionally, for these enabled VFs, their QP0 proxy and tunnel QPs
      are MLX QPs.  As such, they operate over VL15.  Therefore, they are
      not affected by "credit" problems or changes in the VLArb table (which
      may shut down VL0).
      
      Non-enabled VFs may only create UD proxy QP0 qps (which are forced by
      the hypervisor to send packets using the q-key it assigns and places
      in the qp-context).  Thus, non-enabled VFs will not pose a security
      risk.  The hypervisor discards any privileged MADs it receives from
      these non-enabled VFs.
      
      By default, all VFs are NOT enabled, and must explicitly be enabled
      by the administrator.
      
      The sysfs interface which operates the VF enablement infrastructure
      is provided in the next commit.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      99ec41d0
    • J
      IB/mlx4: Preparation for VFs to issue/receive SMI (QP0) requests/responses · 97982f5a
      Jack Morgenstein 提交于
      Currently, VFs in SRIOV VFs are denied QP0 access.  The main reason
      for this decision is security, since Subnet Management Datagrams
      (SMPs) are not restricted by network partitioning and may affect the
      physical network topology.  Moreover, even the SM may be denied access
      from portions of the network by setting management keys unknown to the
      SM.
      
      However, it is desirable to grant SMI access to certain privileged
      VFs, so that certain network management activities may be conducted
      within virtual machines instead of the hypervisor.
      
      This commit does the following:
      
      1. Create QP0 tunnel QPs for all VFs.
      
      2. Discard SMI mads sent-from/received-for non-privileged VFs in the
         hypervisor MAD multiplex/demultiplex logic.  SMI mads from/for
         privileged VFs are allowed to pass.
      
      3. MAD_IFC wrapper changes/fixes.  For non-privileged VFs, only
         host-view MAD_IFC commands are allowed, and only for SMI LID-Routed
         GET mads.  For privileged VFs, there are no restrictions.
      
      This commit does not allow privileged VFs as yet.  To determine if a VF
      is privileged, it calls function mlx4_vf_smi_enabled().  This function
      returns 0 unconditionally for now.
      
      The next two commits allow defining and activating privileged VFs.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      97982f5a
  22. 23 5月, 2014 1 次提交
  23. 15 5月, 2014 1 次提交
  24. 29 3月, 2014 2 次提交
  25. 21 3月, 2014 3 次提交
  26. 13 3月, 2014 1 次提交
    • J
      mlx4: Implement IP based gids support for RoCE/SRIOV · 5ea8bbfc
      Jack Morgenstein 提交于
      Since there is no connection between the MAC/VLAN and the GID
      when using IP-based addressing, the proxy QP1 (running on the
      slave) must pass the source-mac, destination-mac, and vlan_id
      information separately from the GID. Additionally, the Host
      must pass the remote source-mac and vlan_id back to the slave,
      
      This is achieved as follows:
      Outgoing MADs:
          1. Source MAC: obtained from the CQ completion structure
             (struct ib_wc, smac field).
          2. Destination MAC: obtained from the tunnel header
          3. vlan_id: obtained from the tunnel header.
      Incoming MADs
          1. The source (i.e., remote) MAC and vlan_id are passed in
             the tunnel header to the proxy QP1.
      
      VST mode support:
           For outgoing MADs,  the vlan_id obtained from the header is
              discarded, and the vlan_id specified by the Hypervisor is used
              instead.
           For incoming MADs, the incoming vlan_id (in the wc) is discarded, and the
              "invalid" vlan (0xffff)  is substituted when forwarding to the slave.
      Signed-off-by: NMoni Shoua <monis@mellanox.co.il>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ea8bbfc