[ofa-general] Re: NOSRQ misc patch [PATCH V1]

Michael S. Tsirkin mst at dev.mellanox.co.il
Sun Jul 22 07:25:02 PDT 2007


> Quoting Pradeep Satyanarayana <pradeeps at linux.vnet.ibm.com>:
> Subject: Re: NOSRQ misc patch [PATCH V1]
> 
> Michael S. Tsirkin wrote:
> >> Quoting Pradeep Satyanarayana <pradeeps at linux.vnet.ibm.com>:
> >> Subject: Re: NOSRQ misc patch [PATCH V1]
> >>
> >> Michael S. Tsirkin wrote:
> >>>> @@ -1168,9 +1170,9 @@ static struct ib_qp *ipoib_cm_create_tx_
> >>>>  	attr.recv_cq = priv->cq;
> >>>>  	attr.srq = priv->cm.srq;
> >>>>  	attr.cap.max_send_wr = ipoib_sendq_size;
> >>>> -	attr.cap.max_recv_wr = 1;
> >>>> +	attr.cap.max_recv_wr = 0;
> >>>>  	attr.cap.max_send_sge = 1;
> >>>> -	attr.cap.max_recv_sge = 1;
> >>>> +	attr.cap.max_recv_sge = 0;
> >>>>  	attr.sq_sig_type = IB_SIGNAL_ALL_WR;
> >>>>  	attr.qp_type = IB_QPT_RC;
> >>>>  	attr.send_cq = cq;
> >>> I don't see how does this fix things.
> >>> This line 
> >>>>  	attr.srq = priv->cm.srq;
> >>> connected the TX QP to SRQ, making it possible to get packets on this QP.
> >>> But if cm.srq is NULL, and a remote sends a packet on this connection,
> >>> the connection will get closed. Which is a quality of implementation issue.
> >>>
> >> When the QP numbers are exchanged correctly, then it should not receive
> >> a packet on this QP in the first place.
> > 
> > Re-read the RFC. It is perfectly legal to reuse a passive QP for transmitting
> > packets. We don't do this currently but we might in the future.
> 
> I presume you mean passive side for receiving.

A passive side is the one that gets a REQ (look in IB spec section 12.9.6).
Under IPoIB passive side can perform post send on the QP created.
To make this work, I connect the QP to the SRQ on the active side:
>         attr.srq = priv->cm.srq;

However, with your patch, priv->cm.srq might be NULL, which
means that the QP won't be attached to SRQ. This is
a quality of implementation issue that your patch is introducing.

-- 
MST



More information about the general mailing list