> Quoting Pradeep Satyanarayana <[EMAIL PROTECTED]>: > Subject: Re: NOSRQ misc patch [PATCH V1] > > Michael S. Tsirkin wrote: > >> Quoting Pradeep Satyanarayana <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
