- 01 Nov, 2011 1 commit
-
-
Roland Dreier authored
Merge branches 'amso1100', 'cma', 'cxgb3', 'cxgb4', 'fdr', 'ipath', 'ipoib', 'misc', 'mlx4', 'misc', 'nes', 'qib' and 'xrc' into for-next
-
- 31 Oct, 2011 7 commits
-
-
Or Gerlitz authored
Enable the maximum size (128) supported by the device for the shadow vlans table, ignoring the module parameter that overrides it. This table is only used by the IBoE control plane for setting a vlan index into an RC/UC QP context or UD Address Handle. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com>
-
Or Gerlitz authored
There's no need to set the vlan-related fields in an IBoE send WQE control segment: - the vlan to be used by a UD QP is set in the datagram segment. - for GSI (CM) QP, all the headers down to 8021q and MAC are built by the software anyway. Signed-off-by:
-
Or Gerlitz authored
The IBoE port MTU is derived from the corresponding Ethernet netdevice MTU, which can support jumbo frames of 9K, and hence surely supports the max IB mtu of 4K. Signed-off-by:
-
Tom Tucker authored
QPs need to be moved to error before telling the firwmare to shutdown the queue. Otherwise, the application can submit WRs that will never get fetched by the hardware and never flushed by the driver. Signed-off-by:
Kumar Sanghvi <kumaras@chelsio.com> Acked-by:
Steve Wise <swsie@opengridcomputing.com> Signed-off-by:
-
Kumar Sanghvi authored
Commit 01e7da6b ("RDMA/cxgb4: Make sure flush CQ entries are collected on connection close") introduced a potential problem where a CQ's comp_handler can get called simultaneously from different places in the iw_cxgb4 driver. This does not comply with Documentation/infiniband/core_locking.txt, which states that at a given point of time, there should be only one callback per CQ should be active. This problem was reported by Parav Pandit <Parav.Pandit@Emulex.Com>. Based on discussion between Parav Pandit and Steve Wise, this patch fixes the above problem by serializing the calls to a CQ's comp_handler using a spin_lock. Reported-by:
Parav Pandit <Parav.Pandit@Emulex.Com> Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
-
Kumar Sanghvi authored
iw_cxgb3 has a potential problem where a CQ's comp_handler can get called simultaneously from different places in iw_cxgb3 driver. This does not comply with Documentation/infiniband/core_locking.txt, which states that at a given point of time, there should be only one callback per CQ should be active. Such problem was reported by Parav Pandit <Parav.Pandit@Emulex.Com> for iw_cxgb4 driver. Based on discussion between Parav Pandit and Steve Wise, this patch fixes the above problem by serializing the calls to a CQ's comp_handler using a spin_lock. Signed-off-by:
-
Mitko Haralanov authored
Fix an issue where the link would come up after replugging a cable even if it has been DISABLED manually. Signed-off-by:
Mitko Haralanov <mitko@qlogic.com> Signed-off-by:
Mike Marciniszyn <mike.marciniszyn@qlogic.com> Signed-off-by:
-
- 28 Oct, 2011 2 commits
-
-
Marcel Apfelbaum authored
Set the extended active speeds based on the hardware configuration. Signed-off-by:
Marcel Apfelbaum <marcela@dev.mellanox.co.il> Reviewed-by:
Hal Rosenstock <hal@mellanox.com> [ Move FDR-10 handling into ib_link_query_port(). - Roland ] Signed-off-by:
-
Marcel Apfelbaum authored
An Extended Port Info packet is sent to each hw port during HCA init. If it returns without error, we assume the port supports extended port capabilities. Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.com> Signed-off-by:
-
- 21 Oct, 2011 8 commits
-
-
Mitko Haralanov authored
Hold the link state machine until the tuning data is read from the QSFP EEPROM so correct tuning settings are applied before the state machine attempts to bring the link up. Link is also held on cable unplug in case a different cable is used. Signed-off-by:
-
Mike Marciniszyn authored
This was probably present from initial submission. Signed-off-by:
-
Mike Marciniszyn authored
Review of qib_ruc_check_hdr() shows that the s_lock is not required in the normal case. The r_lock is held in all cases, and protects the qp fields that are read. The s_lock will be needed to around the call to qib_migrate_qp() to insure that the send engine sees a consistent set of fields. Signed-off-by:
-
Mike Marciniszyn authored
A new field is added to qib_qp called timeout_jiffies. It is initialized upon create and modify. The field is now used instead of a computation based on qp->timeout. Signed-off-by:
-
Mike Marciniszyn authored
The heavy weight spinlock in qib_lookup_qpn() is replaced with RCU. The hash list itself is now accessed via jhash functions instead of mod. The changes should benefit multiple receive contexts in different processors by not contending for the lock just to read the hash structures. The patch also adds a lookaside_qp (pointer) and a lookaside_qpn in the context. The interrupt handler will test the current packet's qpn against lookaside_qpn if the lookaside_qp pointer is non-NULL. The pointer is NULL'ed when the interrupt handler exits. Signed-off-by:
-
Mike Marciniszyn authored
The context init now saves a shift from rcvegrbufs_perchunk rcvegrbufs_perchunk_shift using ilog2. A BUG_ON() protects the power of 2 assumption. Signed-off-by:
-
Mike Marciniszyn authored
Store both the encoded and decoded MTU in the QP structure as a minor optimization for UC/RC receive routines. Signed-off-by:
-
Mike Marciniszyn authored
The memset for zeroing work completions had been unconditional. This patch removes the memset and moves the zeroing into the work completion with a more explicit field by field set. With this patch, non-ONLY/non-LAST packets will avoid the overhead since they will not generate a completion. Signed-off-by:
-
- 18 Oct, 2011 1 commit
-
-
Dotan Barak authored
Pages that were mapped using ib_dma_map_page() should be unmapped using ib_dma_unmap_page(). Signed-off-by:
Dotan Barak <dotanb@dev.mellanox.co.il> Reviewed-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
- 14 Oct, 2011 2 commits
-
-
Jonathan Lallinger authored
When creating flushed receive CQEs, set the QPID field in the t4_cqe to the SQ QID and not the RQ QID. Otherwise the poll code will not find the correct QP context. Signed-off by: Jonathan Lallinger <jonathan@ogc.us> Signed-off by: Steve Wise <swise@ogc.us> Signed-off-by: -
Kumar Sanghvi authored
At the time when a peer closes the connection, iw_cxgb4 will not send a cq event if ibqp.uobject exists. In that case, its possible for a user application to get blocked in ibv_get_cq_event(). To resolve this, call the cq's comp_handler to unblock any read from ibv_get_cq_event(). This will trigger userspace to poll the cq and collect flush status completions for any pending work requests. Signed-off-by:
-
- 13 Oct, 2011 19 commits
-
-
Sean Hefty authored
Allow processes that share the same XRC domain to open an existing shareable QP. This permits those processes to receive events on the shared QP and transfer ownership, so that any process may modify the QP. The latter allows the creating process to exit, while a remaining process can still transition it for path migration purposes. Signed-off-by:
Sean Hefty <sean.hefty@intel.com> Signed-off-by:
-
Sean Hefty authored
XRC TGT QPs are shared resources among multiple processes. Since the creating process may exit, allow other processes which share the same XRC domain to open an existing QP. This allows us to transfer ownership of an XRC TGT QP to another process. Signed-off-by:
-
Sean Hefty authored
Support the creation of XRC INI and TGT QPs. To handle the case where a CQ or PD is not provided, we allocate them internally with the xrcd. Signed-off-by:
-
Sean Hefty authored
Allow the user to create XRC SRQs. This patch is based on a patch from Jack Morgenstrein <jackm@dev.mellanox.co.il>. Signed-off-by:
-
Sean Hefty authored
Support creating and destroying XRC domains. Any sharing of the XRCD is managed above the low-level driver. Signed-off-by:
-
Sean Hefty authored
Because an XRC TGT QP can end up being shared among multiple processes, don't have the ib_cm automatically send a DREQ when the userspace process that owns the ib_cm_id exits. Disconnect can be initiated by the user directly; otherwise, the owner of the XRC INI QP controls the connection. Note that as a result of the process exiting, the ib_cm will stop tracking the XRC connection on the target side. For the purposes of disconnecting, this isn't a big deal. The ib_cm will respond to the DREQ appropriately. For other messages, mainly LAP, the CM will reject the request, since there's no one available to route the request to. Signed-off-by:
-
Sean Hefty authored
Allow users to connect XRC QPs through the rdma_cm. Signed-off-by:
-
Sean Hefty authored
Allow the user to indicate the QP type separately from the port space when allocating an rdma_cm_id. With RDMA_PS_IB, there is no longer a 1:1 relationship between the QP type and port space, so we need to switch on the QP type to select between UD and connected QPs. Signed-off-by:
-
Sean Hefty authored
Add RDMA_PS_IB. XRC QP types will use the IB port space when operating over the RDMA CM. For the 'IP protocol' field value, we select 0x3F, which is listed as being for 'any local network'. Signed-off-by:
-
Sean Hefty authored
The XRC annex was updated to have XRC behave more like RD. Specifically, the XRC TGT QPN moves from the local QPN to local EECN field. Lookup of SRQN is done using the REQ/REP protocol. Signed-off-by:
-
Sean Hefty authored
Update the REQ and REP messages to support XRC connection setup according to the XRC Annex. Several existing fields must be set to 0 or 1 when connecting XRC QPs, and a reserved field is changed to an extended transport type. Signed-off-by:
-
Sean Hefty authored
Allow user space to operate on XRC TGT QPs the same way as other types of QPs, with one notable exception: since XRC TGT QPs may be shared among multiple processes, the XRC TGT QP is allowed to exist beyond the lifetime of the creating process. The process that creates the QP is allowed to destroy it, but if the process exits without destroying the QP, then the QP will be left bound to the lifetime of the XRCD. TGT QPs are not associated with CQs or a PD. Signed-off-by:
-
Sean Hefty authored
XRC INI QPs are similar to send only RC QPs. Allow user space to create INI QPs. Note that INI QPs do not require receive CQs. Signed-off-by:
-
Sean Hefty authored
We require additional information to create XRC SRQs than we can exchange using the existing create SRQ ABI. Provide an enhanced create ABI for extended SRQ types. Based on patches by Jack Morgenstein <jackm@dev.mellanox.co.il> and Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Sean Hefty authored
Allow user space to create XRC domains. Because XRCDs are expected to be shared among multiple processes, we use inodes to identify an XRCD. Based on patches by Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
-
Sean Hefty authored
XRC TGT QPs are intended to be shared among multiple users and processes. Allow the destruction of an XRC TGT QP to be done explicitly through ib_destroy_qp() or when the XRCD is destroyed. To support destroying an XRC TGT QP, we need to track TGT QPs with the XRCD. When the XRCD is destroyed, all tracked XRC TGT QPs are also cleaned up. To avoid stale reference issues, if a user is holding a reference on a TGT QP, we increment a reference count on the QP. The user releases the reference by calling ib_release_qp. This releases any access to the QP from a user above verbs, but allows the QP to continue to exist until destroyed by the XRCD. Signed-off-by:
-
Sean Hefty authored
XRC ("eXtended reliable connected") is an IB transport that provides better scalability by allowing senders to specify which shared receive queue (SRQ) should be used to receive a message, which essentially allows one transport context (QP connection) to serve multiple destinations (as long as they share an adapter, of course). XRC communication is between an initiator (INI) QP and a target (TGT) QP. Target QPs are associated with SRQs through an XRCD. An XRC TGT QP behaves like a receive-only RD QP. XRC INI QPs behave similarly to RC QPs, except that work requests posted to an XRC INI QP must specify the remote SRQ that is the target of the work request. We define two new QP types for XRC, to distinguish between INI and TGT QPs, and update the core layer to support XRC QPs. This patch is derived from work by Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: -
Sean Hefty authored
XRC ("eXtended reliable connected") is an IB transport that provides better scalability by allowing senders to specify which shared receive queue (SRQ) should be used to receive a message, which essentially allows one transport context (QP connection) to serve multiple destinations (as long as they share an adapter, of course). XRC defines SRQs that are specifically used by XRC connections. Expand the SRQ code to support XRC SRQs. An XRC SRQ is currently restricted to only XRC use according to the IB XRC Annex. Portions of this patch were derived from work by Jack Morgenstein <jackm@dev.mellanox.co.il>. Signed-off-by: -
Sean Hefty authored
Currently, there is only a single ("basic") type of SRQ, but with XRC support we will add a second. Prepare for this by defining an SRQ type and setting all current users to IB_SRQT_BASIC. Signed-off-by:
-
