1. 23 8月, 2017 1 次提交
  2. 24 7月, 2017 5 次提交
  3. 18 7月, 2017 1 次提交
  4. 02 5月, 2017 4 次提交
  5. 26 4月, 2017 1 次提交
  6. 15 2月, 2017 1 次提交
    • T
      IB/mlx4: Take source GID by index from HW GID table · a748d60d
      Talat Batheesh 提交于
      Previously, we used the HW GID index in order to search the source GID
      in the software GID cached table. In some cases, for example when
      the MAC Address of the network interface is changed, the GID cached table
      saves the old-IPv6-link-local GID at the end of the table.
      
      When returning the old MAC address, the software GID cached table tries
      to add the new IPv6-link-local GID, and when it identifies that the GID
      already exists, the software GID cached does not add it. Thus a mismatch
      occurs between the HW and the SW GID tables.
      
      It resulted with sending traffic with the wrong source GID.
      
      This commit fixes the issue by taking both from the HW table.
      
      The problem can be reproduced with the following scenario:
      Client:
          # ifconfig ens6 2.2.2.5
          # ifconfig ens6 inet6 add 2001:0db8:0:f101::5/64
          # ifconfig ens6 hw ether f4:52:14:61:a0:71
          # ifconfig ens6 inet6 del 2001:0db8:0:f101::5/64
          # ifconfig ens6 inet6 add 2001:0db8:0:f101::5/64
          # ucmatose -f ipv6 -b 2001:0db8:0:f101::5 -s 2001:0db8:0:f101::6 -p 20156
      Server:
          # ucmatose -f ipv6 -b 2001:0db8:0:f101::6 -p 20156
      
      Fixes: 4c3eb3ca ('IB/mlx4: Add VLAN support for IBoE')
      Signed-off-by: NTalat Batheesh <talatb@mellanox.com>
      Reviewed-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      a748d60d
  7. 11 1月, 2017 1 次提交
  8. 15 12月, 2016 1 次提交
  9. 14 12月, 2016 2 次提交
  10. 08 10月, 2016 2 次提交
    • J
      IB/mlx4: Fix possible vl/sl field mismatch in LRH header in QP1 packets · fd10ed8e
      Jack Morgenstein 提交于
      In MLX qp packets, the LRH (built by the driver) has both a VL field
      and an SL field. When building a QP1 packet, the VL field should
      reflect the SLtoVL mapping and not arbitrarily contain zero (as is
      done now). This bug causes credit problems in IB switches at
      high rates of QP1 packets.
      
      The fix is to cache the SL to VL mapping in the driver, and look up
      the VL mapped to the SL provided in the send request when sending
      QP1 packets.
      
      For FW versions which support generating a port_management_config_change
      event with subtype sl-to-vl-table-change, the driver uses that event
      to update its sl-to-vl mapping cache.  Otherwise, the driver snoops
      incoming SMP mads to update the cache.
      
      There remains the case where the FW is running in secure-host mode
      (so no QP0 packets are delivered to the driver), and the FW does not
      generate the sl2vl mapping change event. To support this case, the
      driver updates (via querying the FW) its sl2vl mapping cache when
      running in secure-host mode when it receives either a Port Up event
      or a client-reregister event (where the port is still up, but there
      may have been an opensm failover).
      OpenSM modifies the sl2vl mapping before Port Up and Client-reregister
      events occur, so if there is a mapping change the driver's cache will
      be properly updated.
      
      Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      fd10ed8e
    • L
      IB/mlx4: Move user vendor structures · 9ce28a20
      Leon Romanovsky 提交于
      This patch moves mlx4 vendor's specific structures to
      common UAPI folder which will be visible to all consumers.
      
      These structures are used by user-space library driver
      (libmlx4) and currently manually copied to that library.
      
      This move will allow cross-compile against these files and
      simplify introduction of vendor specific data.
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      9ce28a20
  11. 17 9月, 2016 2 次提交
    • J
      IB/mlx4: Use correct subnet-prefix in QP1 mads under SR-IOV · 8ec07bf8
      Jack Morgenstein 提交于
      When sending QP1 MAD packets which use a GRH, the source GID
      (which consists of the 64-bit subnet prefix, and the 64 bit port GUID)
      must be included in the packet GRH.
      
      For SR-IOV, a GID cache is used, since the source GID needs to be the
      slave's source GID, and not the Hypervisor's GID. This cache also
      included a subnet_prefix. Unfortunately, the subnet_prefix field in
      the cache was never initialized (to the default subnet prefix 0xfe80::0).
      As a result, this field remained all zeroes.  Therefore, when SR-IOV
      was active, all QP1 packets which included a GRH had a source GID
      subnet prefix of all-zeroes.
      
      However, the subnet-prefix should initially be 0xfe80::0 (the default
      subnet prefix). In addition, if OpenSM modifies a port's subnet prefix,
      the new subnet prefix must be used in the GRH when sending QP1 packets.
      To fix this we now initialize the subnet prefix in the SR-IOV GID cache
      to the default subnet prefix. We update the cached value if/when OpenSM
      modifies the port's subnet prefix. We take this cached value when sending
      QP1 packets when SR-IOV is active.
      
      Note that the value is stored as an atomic64. This eliminates any need
      for locking when the subnet prefix is being updated.
      
      Note also that we depend on the FW generating the "port management change"
      event for tracking subnet-prefix changes performed by OpenSM. If running
      early FW (before 2.9.4630), subnet prefix changes will not be tracked (but
      the default subnet prefix still will be stored in the cache; therefore
      users who do not modify the subnet prefix will not have a problem).
      IF there is a need for such tracking also for early FW, we will add that
      capability in a subsequent patch.
      
      Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      8ec07bf8
    • J
      IB/mlx4: Fix code indentation in QP1 MAD flow · baa0be70
      Jack Morgenstein 提交于
      The indentation in the QP1 GRH flow in procedure build_mlx_header is
      really confusing. Fix it, in preparation for a commit which touches
      this code.
      
      Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      baa0be70
  12. 20 7月, 2016 1 次提交
  13. 23 6月, 2016 2 次提交
  14. 06 5月, 2016 1 次提交
    • H
      net/mlx4: Avoid wrong virtual mappings · 73898db0
      Haggai Abramovsky 提交于
      The dma_alloc_coherent() function returns a virtual address which can
      be used for coherent access to the underlying memory.  On some
      architectures, like arm64, undefined behavior results if this memory is
      also accessed via virtual mappings that are not coherent.  Because of
      their undefined nature, operations like virt_to_page() return garbage
      when passed virtual addresses obtained from dma_alloc_coherent().  Any
      subsequent mappings via vmap() of the garbage page values are unusable
      and result in bad things like bus errors (synchronous aborts in ARM64
      speak).
      
      The mlx4 driver contains code that does the equivalent of:
      vmap(virt_to_page(dma_alloc_coherent)), this results in an OOPs when the
      device is opened.
      
      Prevent Ethernet driver to run this problematic code by forcing it to
      allocate contiguous memory. As for the Infiniband driver, at first we
      are trying to allocate contiguous memory, but in case of failure roll
      back to work with fragmented memory.
      Signed-off-by: NHaggai Abramovsky <hagaya@mellanox.com>
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Reported-by: NDavid Daney <david.daney@cavium.com>
      Tested-by: NSinan Kaya <okaya@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73898db0
  15. 17 2月, 2016 1 次提交
    • H
      net/mlx4_core: Set UAR page size to 4KB regardless of system page size · 85743f1e
      Huy Nguyen 提交于
      problem description:
      
      The current code sets UAR page size equal to system page size.
      The ConnectX-3 and ConnectX-3 Pro HWs require minimum 128 UAR pages.
      The mlx4 kernel drivers are not loaded if there is less than 128 UAR pages.
      
      solution:
      
      Always set UAR page to 4KB. This allows more UAR pages if the OS
      has PAGE_SIZE larger than 4KB. For example, PowerPC kernel use 64KB
      system page size, with 4MB uar region, there are 4MB/2/64KB = 32
      uars (half for uar, half for blueflame). This does not meet minimum 128
      UAR pages requirement. With 4KB UAR page, there are 4MB/2/4KB = 512 uars
      which meet the minimum requirement.
      
      Note that only codes in mlx4_core that deal with firmware know that uar
      page size is 4KB. Codes that deal with usr page in cq and qp context
      (mlx4_ib, mlx4_en and part of mlx4_core) still have the same assumption
      that uar page size equals to system page size.
      
      Note that with this implementation, on 64KB system page size kernel, there
      are 16 uars per system page but only one uars is used. The other 15
      uars are ignored because of the above assumption.
      
      Regarding SR-IOV, mlx4_core in hypervisor will set the uar page size
      to 4KB and mlx4_core code in virtual OS will obtain the uar page size from
      firmware.
      
      Regarding backward compatibility in SR-IOV, if hypervisor has this new code,
      the virtual OS must be updated. If hypervisor has old code, and the virtual
      OS has this new code, the new code will be backward compatible with the
      old code. If the uar size is big enough, this new code in VF continues to
      work with 64 KB uar page size (on PowerPc kernel). If the uar size does not
      meet 128 uars requirement, this new code not loaded in VF and print the same
      error message as the old code in Hypervisor.
      Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
      Reviewed-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85743f1e
  16. 20 1月, 2016 4 次提交
  17. 24 12月, 2015 3 次提交
  18. 23 12月, 2015 1 次提交
  19. 09 12月, 2015 1 次提交
  20. 29 10月, 2015 2 次提交
  21. 22 10月, 2015 3 次提交