1. 07 6月, 2012 1 次提交
  2. 19 5月, 2012 1 次提交
  3. 14 10月, 2011 2 次提交
  4. 19 7月, 2011 1 次提交
  5. 26 10月, 2010 1 次提交
    • E
      IB/mlx4: Add support for IBoE · fa417f7b
      Eli Cohen 提交于
      Add support for IBoE to mlx4_ib.  The bulk of the code is handling the
      new address vector fields; mlx4 needs the MAC address of a remote node
      to include it in a WQE (for datagrams) or in the QP context (for
      connected QPs).  Address resolution is done by assuming all unicast
      GIDs are either link-local IPv6 addresses.
      
      Multicast group attach/detach needs to update the NIC's multicast
      filters; but since attaching a QP to a multicast group can be done
      before the QP is bound to a port, for IBoE we need to keep track of
      all multicast groups that a QP is attached too before it transitions
      from INIT to RTR (since it does not have a port in the INIT state).
      Signed-off-by: NEli Cohen <eli@mellanox.co.il>
      
      [ Many things cleaned up and otherwise monkeyed with; hope I didn't
        introduce too many bugs.  - Roland ]
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      fa417f7b
  6. 06 9月, 2009 1 次提交
    • J
      IB/mlx4: Don't allow userspace open while recovering from catastrophic error · 3b4a8cd5
      Jack Morgenstein 提交于
      Userspace apps are supposed to release all ib device resources if they
      receive a fatal async event (IBV_EVENT_DEVICE_FATAL).  However, the
      app has no way of knowing when the device has come back up, except to
      repeatedly attempt ibv_open_device() until it succeeds.
      
      However, currently there is no protection against the open succeeding
      while the device is in being removed following the fatal event.  In
      this case, the open will succeed, but as a result the device waits in
      the middle of its removal until the new app releases its resources --
      and the new app will not do so, since the open succeeded at a point
      following the fatal event generation.
      
      This patch adds an "active" flag to the device. The active flag is set
      to false (in the fatal event flow) before the "fatal" event is
      generated, so any subsequent ibv_dev_open() call to the device will
      fail until the device comes back up, thus preventing the above
      deadlock.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      3b4a8cd5
  7. 08 5月, 2009 1 次提交
  8. 23 10月, 2008 1 次提交
  9. 26 7月, 2008 1 次提交
  10. 23 7月, 2008 1 次提交
  11. 15 7月, 2008 1 次提交
  12. 24 4月, 2008 1 次提交
  13. 17 4月, 2008 3 次提交
  14. 09 2月, 2008 1 次提交
    • J
      IB/mlx4: Use multiple WQ blocks to post smaller send WQEs · ea54b10c
      Jack Morgenstein 提交于
      ConnectX HCA supports shrinking WQEs, so that a single work request
      can be made of multiple units of wqe_shift.  This way, WRs can differ
      in size, and do not have to be a power of 2 in size, saving memory and
      speeding up send WR posting.  Unfortunately, if we do this then the
      wqe_index field in CQEs can't be used to look up the WR ID anymore, so
      our implementation does this only if selective signaling is off.
      
      Further, on 32-bit platforms, we can't use vmap() to make the QP
      buffer virtually contigious. Thus we have to use constant-sized WRs to
      make sure a WR is always fully within a single page-sized chunk.
      
      Finally, we use WRs with the NOP opcode to avoid wrapping around the
      queue buffer in the middle of posting a WR, and we set the
      NoErrorCompletion bit to avoid getting completions with error for NOP
      WRs.  However, NEC is only supported starting with firmware 2.2.232,
      so we use constant-sized WRs for older firmware.  And, since MLX QPs
      only support SEND, we use constant-sized WRs in this case.
      
      When stamping during NOP posting, do stamping following setting of the
      NOP WQE valid bit.
      Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      ea54b10c
  15. 10 10月, 2007 1 次提交
  16. 13 7月, 2007 2 次提交
  17. 10 7月, 2007 1 次提交
  18. 18 6月, 2007 1 次提交
    • R
      IB/mlx4: Handle new FW requirement for send request prefetching · 0e6e7416
      Roland Dreier 提交于
      New ConnectX firmware introduces FW command interface revision 2,
      which requires that for each QP, a chunk of send queue entries (the
      "headroom") is kept marked as invalid, so that the HCA doesn't get
      confused if it prefetches entries that haven't been posted yet.  Add
      code to the driver to do this, and also update the user ABI so that
      userspace can request that the prefetcher be turned off for userspace
      QPs (we just leave the prefetcher on for all kernel QPs).
      
      Unfortunately, marking send queue entries this way is confuses older
      firmware, so we change the driver to allow only FW command interface
      revisions 2.  This means that users will have to update their firmware
      to work with the new driver, but the firmware is changing quickly and
      the old firmware has lots of other bugs anyway, so this shouldn't be too
      big a deal.
      
      Based on a patch from Jack Morgenstein <jackm@dev.mellanox.co.il>.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      0e6e7416
  19. 09 5月, 2007 1 次提交
    • R
      IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters · 225c7b1f
      Roland Dreier 提交于
      Add an InfiniBand driver for Mellanox ConnectX adapters.  Because
      these adapters can also be used as ethernet NICs and Fibre Channel 
      HBAs, the driver is split into two modules: 
       
        mlx4_core: Handles low-level things like device initialization and 
          processing firmware commands.  Also controls resource allocation 
          so that the InfiniBand, ethernet and FC functions can share a 
          device without stepping on each other. 
       
        mlx4_ib: Handles InfiniBand-specific things; plugs into the 
          InfiniBand midlayer. 
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      225c7b1f