On Sun, Jul 24, 2011 at 9:43 PM,  <[email protected]> wrote:
> +char *rxe_qp_state_name[] = {
> +     [QP_STATE_RESET]        = "RESET",
> +     [QP_STATE_INIT]         = "INIT",
> +     [QP_STATE_READY]        = "READY",
> +     [QP_STATE_DRAIN]        = "DRAIN",
> +     [QP_STATE_DRAINED]      = "DRAINED",
> +     [QP_STATE_ERROR]        = "ERROR",
> +};

Doesn't the compiler complain about assigning const char* to char* for
the above array definition ? And since this array is only used in this
source file, I think it can be declared static.

> +static int rxe_qp_chk_cap(struct rxe_dev *rxe, struct ib_qp_cap *cap,
> +                       int has_srq)
> +{
> +     if (cap->max_send_wr > rxe->attr.max_qp_wr) {
> +             pr_warn("invalid send wr = %d > %d\n",
> +                     cap->max_send_wr, rxe->attr.max_qp_wr);
> +             goto err1;
> +     }

Context information is missing in the message generated by the above
pr_warn() statement. Shouldn't that be dev_warn() instead ?

> +/* move the qp to the error state */
> +void rxe_qp_error(struct rxe_qp *qp)
> +{
> +     qp->req.state = QP_STATE_ERROR;
> +     qp->resp.state = QP_STATE_ERROR;
> +
> +     /* drain work and packet queues */
> +     rxe_run_task(&qp->resp.task, 1);
> +
> +     if (qp_type(qp) == IB_QPT_RC)
> +             rxe_run_task(&qp->comp.task, 1);
> +     else
> +             __rxe_do_task(&qp->comp.task);
> +     rxe_run_task(&qp->req.task, 1);
> +}

A quote from the InfiniBand Architecture Specification:

o11-5.2.5: If the HCA supports SRQ, for RC and UD service, the CI
shall generate a Last WQE Reached Affiliated Asynchronous Event on a
QP that is in the Error State and is associated with an SRQ when
either:
• a CQE is generated for the last WQE, or
• the QP gets in the Error State and there are no more WQEs on the RQ.

I haven't found the code yet for generating the last WQE event in the
ib_rxe implementation ?

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to