[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
On Thu, 2004-11-11 at 20:41, Sean Hefty wrote: > This patch recovers from send queue errors on QP 0/1. (It should also "work" > in the case > of fatal errors, but does not try to recover.) Code was tested by forcing > send errors and > checking that the port could still go to active. > > Patch can be applied separately from patch to mthca, but requires other patch > to work > properly. I am having difficulty applying this patch. For some reason, all the changes are rejected. Could this be a patch version issue ? My version of patch is 2.5.4. Should I upgrade and try ? -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] Enable inet6 on ib interface
Roland Dreier wrote: > Tom> Would you really bring both interfaces up? If this is a > Tom> problem, the spec should have the pkey be part of the link > Tom> local address. > > It actually seems to work fine to bring up multiple IPv6 interfaces > that end up with the same link local address (like ib0 and ib0.8001). > The fact that Linux forces you to specify an interface when using a > link local address comes to the rescue. And I can't think of any > issues, since different partitions are really pretty disjoint. Btw on vlan, I know that vlan-id's are a part of link local addresses. That way all the link local addresses are unique and as a result during DAD process they join different solicited multicast groups. Thanks Nitin > > - R. > > ___ > openib-general mailing list > [EMAIL PROTECTED] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] New OpenIB webpages
Matt> FAQ wiki does sound good. I'll look into it. In general having a wiki would be great (there have been a few times in the past where I would have liked to have been able to create a quick wiki page). - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: PD dealloc and AH busy problems remain
On Thu, 2004-11-11 at 23:41, Roland Dreier wrote: > Thanks for pointing this out, it was the kick in the rear I needed to > really investigate this. It turns out there were two bugs (I think). > In any case my logs are clean with these changes. So are mine now :-) I'll keep an eye on this reoccuring but otherwise assume this is fixed. Thanks. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] Enable inet6 on ib interface
On Thu, 2004-11-11 at 19:46, Roland Dreier wrote: > In fact I don't see how Solaris can deduce the interface from > a link local IPv6 address... I don't see how this would work either (at least for Linux): Here's my config: eth1 inet6 addr: fe80::230:48ff:fe27:212f/64 Scope:Link ib0 inet6 addr: fe80::208:f104:396:71/64 Scope:Link ip -6 route show fe80::/64 dev eth1 metric 256 mtu 1500 advmss 1440 fe80::/64 dev ib0 metric 256 mtu 2044 advmss 1984 ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 ff00::/8 dev ib0 metric 256 mtu 2044 advmss 1984 So some help looks like it is needed to select the outgoing local interface. It's not just a routing calculating on the destination address as it appears to be in Solaris. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
Hal Rosenstock wrote: On Thu, 2004-11-11 at 20:41, Sean Hefty wrote: This patch recovers from send queue errors on QP 0/1. (It should also "work" in the case of fatal errors, but does not try to recover.) Code was tested by forcing send errors and checking that the port could still go to active. Patch can be applied separately from patch to mthca, but requires other patch to work properly. I am having difficulty applying this patch. For some reason, all the changes are rejected. Could this be a patch version issue ? My version of patch is 2.5.4. Should I upgrade and try ? Not sure what the issue is. Let me make sure that I've pulled the latest code and resubmit the patch. - Sean ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [2/2] change QP state to SQE
Roland Dreier wrote: Sean> This should transition the QP state to SQE when encountering Sean> a send error on the CQ. There may be a better way of doing Sean> this; I didn't spend a lot of time studying the code. Thanks for the patch... let me look at how I want to do this (and probably handle transitions to ERR while I'm at it). That's fine. This was just the easiest change that I could find in order to test my mad changes. - Sean ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
On Fri, 2004-11-12 at 12:13, Sean Hefty wrote: > Not sure what the issue is. Let me make sure that I've pulled the latest > code and > resubmit the patch. It looks right to me. Does it work for you ? Can you send a normal rather than unified diff ? -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] agent: Fix agent_mad_send PCI mapping and gather address and length
Hal Rosenstock wrote: On Wed, 2004-11-10 at 11:59, Roland Dreier wrote: Sean> What exactly does it mean then when process_mad returns Sean> success? Do any of the return bits from process_mad Sean> indicate that the MAD was for the HCA driver? SUCCESS means that process_mad didn't encounter any errors. If REPLY or CONSUMED is set then process_mad actually handled the packet. I would assume that REPLY and CONSUMED are also mutually exclusive. I believe that's the case, but maybe it would make more sense if they weren't, and let CONSUMED indicate that MAD was for the HCA driver. From an API perspective, I think we only need to know if the HCA driver intercepted the MAD, and if so, was a reply generated. - Sean ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [2/2] change QP state to SQE
I thought about this a little, and it seems that having the CQ poll operation update the QP state is not the right solution. It seems it would be better to add support for the "Current QP state" modifier for the modify QP operation and expect the consumer to use that to indicate that the QP is in SQE state. - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [2/2] change QP state to SQE
Roland Dreier wrote: I thought about this a little, and it seems that having the CQ poll operation update the QP state is not the right solution. It seems it would be better to add support for the "Current QP state" modifier for the modify QP operation and expect the consumer to use that to indicate that the QP is in SQE state. That would work fine, and be only a minor update to the MAD code. Will you be generated a patch for mthca? - Sean ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
On Fri, 12 Nov 2004 12:18:32 -0500
Hal Rosenstock <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-11-12 at 12:13, Sean Hefty wrote:
> > Not sure what the issue is. Let me make sure that I've pulled the latest
> > code and
> > resubmit the patch.
>
> It looks right to me. Does it work for you ? Can you send a normal
> rather than unified diff ?
Can you try this version? I'll also revert back to the original code and see if
I can apply the patch.
- Sean
Index: include/ib_mad.h
===
--- include/ib_mad.h(revision 1221)
+++ include/ib_mad.h(working copy)
@@ -250,6 +250,8 @@
* @mad_agent - Specifies the associated registration to post the send to.
* @send_wr - Specifies the information needed to send the MAD(s).
* @bad_send_wr - Specifies the MAD on which an error was encountered.
+ *
+ * Sent MADs are not guaranteed to complete in the order that they were posted.
*/
int ib_post_send_mad(struct ib_mad_agent *mad_agent,
struct ib_send_wr *send_wr,
Index: core/mad.c
===
--- core/mad.c (revision 1221)
+++ core/mad.c (working copy)
@@ -90,6 +90,8 @@
struct ib_mad_send_wc *mad_send_wc);
static void timeout_sends(void *data);
static int solicited_mad(struct ib_mad *mad);
+static int ib_mad_change_qp_state_to_rts(struct ib_qp *qp,
+enum ib_qp_state cur_state);
/*
* Returns a ib_mad_port_private structure or NULL for a device/port.
@@ -591,6 +593,7 @@
/* Timeout will be updated after send completes */
mad_send_wr->timeout = msecs_to_jiffies(send_wr->wr.
ud.timeout_ms);
+ mad_send_wr->retry = 0;
/* One reference for each work request to QP + response */
mad_send_wr->refcount = 1 + (mad_send_wr->timeout > 0);
mad_send_wr->status = IB_WC_SUCCESS;
@@ -1339,6 +1342,70 @@
}
}
+static void mark_sends_for_retry(struct ib_mad_qp_info *qp_info)
+{
+ struct ib_mad_send_wr_private *mad_send_wr;
+ struct ib_mad_list_head *mad_list;
+ int flags;
+
+ spin_lock_irqsave(&qp_info->send_queue.lock, flags);
+ list_for_each_entry(mad_list, &qp_info->send_queue.list, list) {
+ mad_send_wr = container_of(mad_list,
+ struct ib_mad_send_wr_private,
+ mad_list);
+ mad_send_wr->retry = 1;
+ }
+ spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
+}
+
+static void mad_error_handler(struct ib_mad_port_private *port_priv,
+ struct ib_wc *wc)
+{
+ struct ib_mad_list_head *mad_list;
+ struct ib_mad_qp_info *qp_info;
+ struct ib_mad_send_wr_private *mad_send_wr;
+ int ret;
+
+ /* Determine if failure was a send or receive */
+ mad_list = (struct ib_mad_list_head *)(unsigned long)wc->wr_id;
+ qp_info = mad_list->mad_queue->qp_info;
+ if (mad_list->mad_queue == &qp_info->recv_queue) {
+ /*
+ * Receive errors indicate that the QP has entered the error
+ * state - error handling/shutdown code will cleanup.
+ */
+ return;
+ }
+
+ /*
+* Send errors will transition the QP to SQE - move
+* QP to RTS and repost flushed work requests.
+*/
+ mad_send_wr = container_of(mad_list, struct ib_mad_send_wr_private,
+ mad_list);
+ if (wc->status == IB_WC_WR_FLUSH_ERR) {
+ if (mad_send_wr->retry) {
+ /* Repost send. */
+ struct ib_send_wr *bad_send_wr;
+
+ mad_send_wr->retry = 0;
+ ret = ib_post_send(qp_info->qp, &mad_send_wr->send_wr,
+ &bad_send_wr);
+ if (ret)
+ ib_mad_send_done_handler(port_priv, wc);
+ } else
+ ib_mad_send_done_handler(port_priv, wc);
+ } else {
+ /* Transition QP to RTS and fail offending send. */
+ ret = ib_mad_change_qp_state_to_rts(qp_info->qp, IB_QPS_SQE);
+ if (ret)
+ printk(KERN_ERR PFX "mad_error_handler - unable to "
+ "transition QP to RTS : %d\n", ret);
+ ib_mad_send_done_handler(port_priv, wc);
+ mark_sends_for_retry(qp_info);
+ }
+}
+
/*
* IB MAD completion callback
*/
@@ -1346,34 +1413,25 @@
{
struct ib_mad_port_private *port_priv;
struct ib_wc wc;
- struct ib_mad_list_head *mad_list;
- struct ib_mad_qp_info *qp_info;
port_priv = (struct ib_mad_port_priv
[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
On Fri, 2004-11-12 at 12:54, Sean Hefty wrote: > On Fri, 12 Nov 2004 12:18:32 -0500 > Can you try this version? I'll also revert back to the original code and see > if > I can apply the patch. Don't bother (if you haven't already). This patch worked. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [1/2] SQE handling on MAD QPs
On Fri, 2004-11-12 at 12:54, Sean Hefty wrote: > Can you try this version? Thanks. Applied. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] OpenIB gen1 stack u/kDAPL by NTT DATA
Hi Masanori, Matt Leninger from Sandia controls who has access to the svn tree. You should probably contact him for providing contributions. cheers woody -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Masanori ITOH Sent: Thursday, November 11, 2004 10:14 PM To: [EMAIL PROTECTED] Subject: [openib-general] OpenIB gen1 stack u/kDAPL by NTT DATA Hello folks, As I mentioned fomerly on this list, I have a working u/kDAPL on top of the gen1 stack and I've finally finished all internal procedures to make it public. # Actually, it took me about one month and a half. Sigh... :( I would like to put that into the OpenIB contributors area (Somewhere like 'https://openib.org/svn/trunk/contrib/nttdata/'.), and could anyone tell me how I can do that? Thanks in advance, Masanori --- Masanori ITOH Open Source Software Development Center, NTT DATA CORPORATION e-mail: [EMAIL PROTECTED] phone : +81-3-3523-8122 (ext. 172-7199) ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [2/2] change QP state to SQE
Sean> That would work fine, and be only a minor update to the MAD Sean> code. Will you be generated a patch for mthca? Yes, eventually. (ib_verbs.h will also need an update to add the field to ib_qp_attr) - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] Remove unneeded call in MAD code
This patch removes ib_mad_return_posted_send_mads, which isn't needed when
shutting down. There cannot be any sends outstanding at this point, or
clients still exist.
- Sean
Index: core/mad.c
===
--- core/mad.c (revision 1222)
+++ core/mad.c (working copy)
@@ -1692,21 +1692,6 @@
}
/*
- * Return all the posted send MADs
- */
-static void ib_mad_return_posted_send_mads(struct ib_mad_qp_info *qp_info)
-{
- unsigned long flags;
-
- /* Just clear port send posted MAD list... revisit!!! */
- spin_lock_irqsave(&qp_info->send_queue.lock, flags);
- INIT_LIST_HEAD(&qp_info->send_queue.list);
- qp_info->send_queue.count = 0;
- INIT_LIST_HEAD(&qp_info->overflow_list);
- spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
-}
-
-/*
* Modify QP into Init state
*/
static inline int ib_mad_change_qp_state_to_init(struct ib_qp *qp)
@@ -1909,7 +1894,6 @@
i);
}
ib_mad_return_posted_recv_mads(&port_priv->qp_info[i]);
- ib_mad_return_posted_send_mads(&port_priv->qp_info[i]);
}
}
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] Remove unneeded call in MAD code
On Fri, 2004-11-12 at 15:39, Sean Hefty wrote: > This patch removes ib_mad_return_posted_send_mads, which isn't needed when > shutting down. There cannot be any sends outstanding at this point, or > clients still exist. Thanks. Applied. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] collapse MAD function calls
This patch callapses several function calls into one when activating
the MAD QPs. This avoids repeated allocation/freeing of memory.
I have plans to examine the QP transitions to the reset
state to see if these are necessary and if a race condition exists
between shutting down a port and processing a receive completion.
- Sean
Index: core/mad.c
===
--- core/mad.c (revision 1222)
+++ core/mad.c (working copy)
@@ -90,8 +90,6 @@
struct ib_mad_send_wc *mad_send_wc);
static void timeout_sends(void *data);
static int solicited_mad(struct ib_mad *mad);
-static int ib_mad_change_qp_state_to_rts(struct ib_qp *qp,
-enum ib_qp_state cur_state);
/*
* Returns a ib_mad_port_private structure or NULL for a device/port
@@ -1396,13 +1394,21 @@
} else
ib_mad_send_done_handler(port_priv, wc);
} else {
+ struct ib_qp_attr *attr;
+
/* Transition QP to RTS and fail offending send */
- ret = ib_mad_change_qp_state_to_rts(qp_info->qp, IB_QPS_SQE);
- if (ret)
- printk(KERN_ERR PFX "mad_error_handler - unable to "
- "transition QP to RTS : %d\n", ret);
+ attr = kmalloc(sizeof *attr, GFP_KERNEL);
+ if (attr) {
+ attr->qp_state = IB_QPS_RTS;
+ ret = ib_modify_qp(qp_info->qp, attr, IB_QP_STATE);
+ kfree(attr);
+ if (ret)
+ printk(KERN_ERR PFX "mad_error_handler - "
+ "ib_modify_qp to RTS : %d\n", ret);
+ else
+ mark_sends_for_retry(qp_info);
+ }
ib_mad_send_done_handler(port_priv, wc);
- mark_sends_for_retry(qp_info);
}
}
@@ -1692,172 +1698,51 @@
}
/*
- * Return all the posted send MADs
- */
-static void ib_mad_return_posted_send_mads(struct ib_mad_qp_info *qp_info)
-{
- unsigned long flags;
-
- /* Just clear port send posted MAD list... revisit!!! */
- spin_lock_irqsave(&qp_info->send_queue.lock, flags);
- INIT_LIST_HEAD(&qp_info->send_queue.list);
- qp_info->send_queue.count = 0;
- INIT_LIST_HEAD(&qp_info->overflow_list);
- spin_unlock_irqrestore(&qp_info->send_queue.lock, flags);
-}
-
-/*
- * Modify QP into Init state
- */
-static inline int ib_mad_change_qp_state_to_init(struct ib_qp *qp)
-{
- int ret;
- struct ib_qp_attr *attr;
- int attr_mask;
-
- attr = kmalloc(sizeof *attr, GFP_KERNEL);
- if (!attr) {
- printk(KERN_ERR PFX "Couldn't allocate memory for "
- "ib_qp_attr\n");
- return -ENOMEM;
- }
-
- attr->qp_state = IB_QPS_INIT;
- /*
-* PKey index for QP1 is irrelevant but
-* one is needed for the Reset to Init transition.
-*/
- attr->pkey_index = 0;
- /* QKey is 0 for QP0 */
- if (qp->qp_num == 0)
- attr->qkey = 0;
- else
- attr->qkey = IB_QP1_QKEY;
- attr_mask = IB_QP_STATE | IB_QP_PKEY_INDEX | IB_QP_QKEY;
-
- ret = ib_modify_qp(qp, attr, attr_mask);
- kfree(attr);
-
- if (ret)
- printk(KERN_WARNING PFX "ib_mad_change_qp_state_to_init "
- "ret = %d\n", ret);
- return ret;
-}
-
-/*
- * Modify QP into Ready-To-Receive state
- */
-static inline int ib_mad_change_qp_state_to_rtr(struct ib_qp *qp)
-{
- int ret;
- struct ib_qp_attr *attr;
- int attr_mask;
-
- attr = kmalloc(sizeof *attr, GFP_KERNEL);
- if (!attr) {
- printk(KERN_ERR PFX "Couldn't allocate memory for "
- "ib_qp_attr\n");
- return -ENOMEM;
- }
-
- attr->qp_state = IB_QPS_RTR;
- attr_mask = IB_QP_STATE;
-
- ret = ib_modify_qp(qp, attr, attr_mask);
- kfree(attr);
-
- if (ret)
- printk(KERN_WARNING PFX "ib_mad_change_qp_state_to_rtr "
- "ret = %d\n", ret);
- return ret;
-}
-
-/*
- * Modify QP into Ready-To-Send state
- */
-static int ib_mad_change_qp_state_to_rts(struct ib_qp *qp,
-enum ib_qp_state cur_state)
-{
- int ret;
- struct ib_qp_attr *attr;
- int attr_mask;
-
- attr = kmalloc(sizeof *attr, GFP_KERNEL);
- if (!attr) {
- printk(KERN_ERR PFX "Couldn't allocate memory for "
- "ib_qp_attr\n");
- return -ENOMEM;
- }
- attr->qp_state = IB_QPS_RTS;
- attr_mask = IB_QP_STATE;
- if (cur_state == IB_QPS_RTR) {
- attr->sq_psn = IB_MAD_SEND_Q_PSN;
- attr_mask |= IB_QP_SQ_PSN;
-
[openib-general] Re: [PATCH] collapse MAD function calls
On Fri, 2004-11-12 at 19:45, Sean Hefty wrote: > This patch callapses several function calls into one when activating > the MAD QPs. This avoids repeated allocation/freeing of memory. > > I have plans to examine the QP transitions to the reset > state to see if these are necessary and if a race condition exists > between shutting down a port and processing a receive completion. This patch looks like it includes the previous patch and due to this 2 large hunks are rejected. Can you regenerate this ? -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] Re: [PATCH] collapse MAD function calls
>On Fri, 2004-11-12 at 19:45, Sean Hefty wrote: >> This patch callapses several function calls into one when activating >> the MAD QPs. This avoids repeated allocation/freeing of memory. >> >> I have plans to examine the QP transitions to the reset >> state to see if these are necessary and if a race condition exists >> between shutting down a port and processing a receive completion. > >This patch looks like it includes the previous patch and due to this 2 >large hunks are rejected. Can you regenerate this ? Oops, sorry about that. I'll do this as soon as I get back in touch with my systems. - Sean ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [2/2] change QP state to SQE
OK, here's a patch that adds support for "Current QP state" in the
modify QP verb. Does this look OK?
Thanks,
Roland
Index: infiniband/include/ib_verbs.h
===
--- infiniband/include/ib_verbs.h (revision 1223)
+++ infiniband/include/ib_verbs.h (working copy)
@@ -421,7 +421,8 @@
enum ib_qp_attr_mask {
IB_QP_STATE = 1,
- IB_QP_EN_SQD_ASYNC_NOTIFY = (1<<1),
+ IB_QP_CUR_STATE = (1<<1),
+ IB_QP_EN_SQD_ASYNC_NOTIFY = (1<<2),
IB_QP_ACCESS_FLAGS = (1<<3),
IB_QP_PKEY_INDEX= (1<<4),
IB_QP_PORT = (1<<5),
@@ -460,6 +461,7 @@
struct ib_qp_attr {
enum ib_qp_stateqp_state;
+ enum ib_qp_statecur_qp_state;
enum ib_mtu path_mtu;
enum ib_mig_state path_mig_state;
u32 qkey;
Index: infiniband/hw/mthca/mthca_qp.c
===
--- infiniband/hw/mthca/mthca_qp.c (revision 1223)
+++ infiniband/hw/mthca/mthca_qp.c (working copy)
@@ -394,13 +394,16 @@
[MLX] = IB_QP_SQ_PSN,
},
.opt_param = {
- [UD] = IB_QP_QKEY,
- [RC] = (IB_QP_ALT_PATH |
+ [UD] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
+ [RC] = (IB_QP_CUR_STATE |
+IB_QP_ALT_PATH |
IB_QP_ACCESS_FLAGS |
IB_QP_PKEY_INDEX|
IB_QP_MIN_RNR_TIMER |
IB_QP_PATH_MIG_STATE),
- [MLX] = IB_QP_QKEY,
+ [MLX] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
}
}
},
@@ -410,12 +413,14 @@
[IB_QPS_RTS] = {
.trans = MTHCA_TRANS_RTS2RTS,
.opt_param = {
- [UD] = IB_QP_QKEY,
+ [UD] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
[RC] = (IB_QP_ACCESS_FLAGS |
IB_QP_ALT_PATH |
IB_QP_PATH_MIG_STATE|
IB_QP_MIN_RNR_TIMER),
- [MLX] = IB_QP_QKEY,
+ [MLX] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
}
},
[IB_QPS_SQD] = {
@@ -427,9 +432,36 @@
[IB_QPS_ERR] = { .trans = MTHCA_TRANS_ANY2ERR },
[IB_QPS_RTS] = {
.trans = MTHCA_TRANS_SQD2RTS,
+ .opt_param = {
+ [UD] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
+ [RC] = (IB_QP_CUR_STATE |
+IB_QP_ALT_PATH |
+IB_QP_ACCESS_FLAGS |
+IB_QP_MIN_RNR_TIMER |
+IB_QP_PATH_MIG_STATE),
+ [MLX] = (IB_QP_CUR_STATE |
+IB_QP_QKEY),
+ }
},
[IB_QPS_SQD] = {
.trans = MTHCA_TRANS_SQD2SQD,
+ .opt_param = {
+ [UD] = (IB_QP_PKEY_INDEX|
+IB_QP_QKEY),
+ [RC] = (IB_QP_TIMEOUT |
+IB_QP_RETRY_CNT |
+IB_QP_RNR_RETRY |
+IB_QP_MAX_QP_RD_ATOMIC |
+IB_QP_CUR_STATE |
+IB_QP_ALT_PATH |
+IB_QP_ACCESS_FLAGS |
+IB_QP_PKEY_INDEX|
+IB_QP_MIN_RNR_TIMER |
+IB_QP_PATH_MIG_STATE),
+ [MLX] = (IB_QP_PKEY_INDEX|
+
