1. 20 11月, 2009 1 次提交
    • S
      RDMA/cm: fix loopback address support · 6f8372b6
      Sean Hefty 提交于
      The RDMA CM is intended to support the use of a loopback address
      when establishing a connection; however, the behavior of the CM
      when loopback addresses are used is confusing and does not always
      work, depending on whether loopback was specified by the server,
      the client, or both.
      
      The defined behavior of rdma_bind_addr is to associate an RDMA
      device with an rdma_cm_id, as long as the user specified a non-
      zero address.  (ie they weren't just trying to reserve a port)
      Currently, if the loopback address is passed to rdam_bind_addr,
      no device is associated with the rdma_cm_id.  Fix this.
      
      If a loopback address is specified by the client as the destination
      address for a connection, it will fail to establish a connection.
      This is true even if the server is listing across all addresses or
      on the loopback address itself.  The issue is that the server tries
      to translate the IP address carried in the REQ message to a local
      net_device address, which fails.  The translation is not needed in
      this case, since the REQ carries the actual HW address that should
      be used.
      
      Finally, cleanup loopback support to be more transport neutral.
      Replace separate calls to get/set the sgid and dgid from the
      device address to a single call that behaves correctly depending
      on the format of the device address.  And support both IPv4 and
      IPv6 address formats.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      
      [ Fixed RDS build by s/ib_addr_get/rdma_addr_get/  - Roland ]
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      6f8372b6
  2. 17 11月, 2009 1 次提交
    • S
      RDMA/ucma: Add option to manually set IB path · a7ca1f00
      Sean Hefty 提交于
      Export rdma_set_ib_paths to user space to allow applications to
      manually set the IB path used for connections.  This allows
      alternative ways for a user space application or library to obtain
      path record information, including retrieving path information
      from cached data, avoiding direct interaction with the IB SA.
      The IB SA is a single, centralized entity that can limit scaling
      on large clusters running MPI applications.
      
      Future changes to the rdma cm can expand on this framework to
      support the full range of features allowed by the IB CM, such as
      separate forward and reverse paths and APM.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Reviewed-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      a7ca1f00
  3. 12 10月, 2009 1 次提交
  4. 11 10月, 2008 1 次提交
  5. 05 8月, 2008 1 次提交
    • R
      RDMA/cma: Remove padding arrays by using struct sockaddr_storage · 3f446754
      Roland Dreier 提交于
      There are a few places where the RDMA CM code handles IPv6 by doing
      
      	struct sockaddr		addr;
      	u8			pad[sizeof(struct sockaddr_in6) -
      				    sizeof(struct sockaddr)];
      
      This is fragile and ugly; handle this in a better way with just
      
      	struct sockaddr_storage	addr;
      
      [ Also roll in patch from Aleksey Senin <alekseys@voltaire.com> to
        switch to struct sockaddr_storage and get rid of padding arrays in
        struct rdma_addr. ]
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      3f446754
  6. 25 7月, 2008 1 次提交
  7. 21 6月, 2008 1 次提交
  8. 17 4月, 2008 1 次提交
  9. 26 1月, 2008 1 次提交
    • S
      RDMA/cma: add support for rdma_migrate_id() · 88314e4d
      Sean Hefty 提交于
      This is based on user feedback from Doug Ledford at RedHat:
      
      Events that occur on an rdma_cm_id are reported to userspace through an
      event channel.  Connection request events are reported on the event
      channel associated with the listen.  When the connection is accepted, a
      new rdma_cm_id is created and automatically uses the listen event
      channel.  This is suboptimal where the user only wants listen events on
      that channel.
      
      Additionally, it may be desirable to have events related to connection
      establishment use a different event channel than those related to
      already established connections.
      
      Allow the user to migrate an rdma_cm_id between event channels. All
      pending events associated with the rdma_cm_id are moved to the new event
      channel.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      88314e4d
  10. 10 10月, 2007 1 次提交
  11. 25 4月, 2007 1 次提交
  12. 07 3月, 2007 1 次提交
  13. 17 2月, 2007 1 次提交
    • S
      RDMA/cma: Add multicast communication support · c8f6a362
      Sean Hefty 提交于
      Extend rdma_cm to support multicast communication.  Multicast support
      is added to the existing RDMA_PS_UDP port space, as well as a new
      RDMA_PS_IPOIB port space.  The latter port space allows joining the
      multicast groups used by IPoIB, which enables offloading IPoIB traffic
      to a separate QP.  The port space determines the signature used in the
      MGID when joining the group.  The newly added RDMA_PS_IPOIB also
      allows for unicast operations, similar to RDMA_PS_UDP.
      
      Supporting the RDMA_PS_IPOIB requires changing how UD QPs are initialized,
      since we can no longer assume that the qkey is constant.  This requires
      saving the Q_Key to use when attaching to a device, so that it is
      available when creating the QP.  The Q_Key information is exported to
      the user through the existing rdma_init_qp_attr() interface.
      
      Multicast support is also exported to userspace through the rdma_ucm.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      c8f6a362
  14. 13 2月, 2007 1 次提交
  15. 08 1月, 2007 2 次提交
    • S
      RDMA/ucma: Don't report events with invalid user context · 0cefcf0b
      Sean Hefty 提交于
      There's a problem with how rdma cm events are reported to userspace
      that can lead to application crashes.
      
      When a new connection request arrives, a context for the connection is
      allocated in the kernel.  The connection event is then reported to
      userspace.  The userspace library retrieves the event and allocates
      its own context for the connection.  The userspace context is
      associated with the kernel's context when accepting.  This allows the
      kernel to give userspace context with other events.
      
      A problem occurs if a second event for the same connection occurs
      before the user has had a chance to call accept.  The userspace
      context has not yet been set, which causes the librdmacm to crash.
      (This has been seen when the app takes too long to call accept,
      resulting in the remote side timing out and rejecting the connection)
      
      Fix this by ignoring events for new connections until userspace has
      set their context.  This can only happen if an error occurs on a new
      connection before the user accepts it.  This is okay, since the accept
      will just fail later.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      0cefcf0b
    • S
      RDMA/ucma: Fix struct ucma_event leak when backlog is full · 30a5ec98
      Sean Hefty 提交于
      We discard new connection requests while the listen backlog is full,
      but leak a struct ucma_event in the process.  Free the structure in
      this case.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      30a5ec98
  16. 13 12月, 2006 1 次提交