[ofa-general] IPoIB CM (NOSRQ) [Patch V9] revised

[Pradeep Satyanarayana]

Sean Hefty wrote:
>> @@ -313,19 +483,18 @@ static int ipoib_cm_req_handler(struct i
>> 	}
>>
>> 	psn = random32() & 0xffffff;
>> -	ret = ipoib_cm_modify_rx_qp(dev, cm_id, p->qp, psn);
>> -	if (ret)
>> -		goto err_modify;
>> -
>> -	spin_lock_irq(&priv->lock);
>> -	queue_delayed_work(ipoib_workqueue,
>> -			   &priv->cm.stale_task, IPOIB_CM_RX_DELAY);
>> -	/* Add this entry to passive ids list head, but do not re-add it
>> -	 * if IB_EVENT_QP_LAST_WQE_REACHED has moved it to flush list. */
>> -	p->jiffies = jiffies;
>> -	if (p->state == IPOIB_CM_RX_LIVE)
>> -		list_move(&p->list, &priv->cm.passive_ids);
>> -	spin_unlock_irq(&priv->lock);
>> +	if (!priv->cm.srq) {
>> +		ret = allocate_and_post_rbuf_nosrq(cm_id, p, psn);
>> +		if (ret)
>> +			goto err_modify;
>> +	} else {
>> +		p->rx_ring = NULL;
>> +		ret = ipoib_cm_modify_rx_qp(dev, cm_id, p->qp, psn);
>> +		if (ret)
>> +			goto err_modify;
>> +		p->state = IPOIB_CM_RX_LIVE;
>> +		init_context_and_add_list(cm_id, p, priv);
> 
> I missed this impact in my previous review.  Removing the locking from
> init_context_and_add_list() means that we need a lock here.
> 
Yes, you are correct. The no srq case is correct. This impacts the srq
case. I will fix that.

Pradeep