[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <OFB2B4DC29.734DA538-ONC12577B5.00304CFF-C12577B5.00335EA8@ch.ibm.com>
Date: Thu, 7 Oct 2010 11:21:05 +0200
From: Bernard Metzler <BMT@...ich.ibm.com>
To: Bart Van Assche <bvanassche@....org>
Cc: linux-rdma@...r.kernel.org, linux-rdma-owner@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] SIW: Queue pair
linux-rdma-owner@...r.kernel.org wrote on 10/06/2010 07:57:29 PM:
> On Tue, Oct 5, 2010 at 8:55 AM, Bernard Metzler <bmt@...ich.ibm.com>
wrote:
> >
> > [ ... ]
> > +int
> > +siw_qp_modify(struct siw_qp *qp, struct siw_qp_attrs *attrs,
> > + enum siw_qp_attr_mask mask)
> > +{
> > [ ... ]
> > + case SIW_QP_STATE_ERROR:
> > + siw_rq_flush(qp);
> > + qp->attrs.state = SIW_QP_STATE_ERROR;
> > + drop_conn = 1;
> > + break;
>
> At least for InfiniBand when the state of a queue pair is changed to
> Error, work requests must be completed in error. The above code just
> flushes pending work requests. That doesn't look correct to me.
>
> A quote from the InfiniBand Architecture Specification, table 91, QP
> State Transition Properties:
>
> Any state to Reset: QP attributes are reset to the same values after
> the QP was created. Outstanding Work Requests are removed from the
> queues without notifying the Consumer.
>
right. i was trying to follow the verbs specification, which makes the
same statement - see sec. 6.2.4 of the Hilland vers:
The following is done on entry into the Error state:
* The RI MUST flush any incomplete WRs on the SQ or RQ. All WQEs
on the SQ and RQ, except for the WQE that caused the error (if
any), MUST be returned with the Flushed Error Completion Status
through the Completion Queue associated with the WQ.
following that, siw_rq_flush() flushes to the CQ. so, i think, we are
in sync here (the code flushes only the RQ to the CQ here, since we come
from IDLE or RTR, which must not have anything on the SQ).
thanks,
bernard.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists