[ofa-general] Re: NOSRQ misc patch [PATCH V1]
Pradeep Satyanarayana
pradeeps at linux.vnet.ibm.com
Sun Jul 22 07:13:11 PDT 2007
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. Let us revisit the issue when there
is a need. At this point it is not relevant.
Pradeep
More information about the general
mailing list