<br>I have been looking at the IPoIB CM code and have some queries. I'd greatly appreciate it if some one could shed some light on it.<br><br>Please correct me if I am wrong, but based on my understanding of the code:<br>
<br>1) From functions ipoib_cm_create_tx_qp and ipoib_cm_create_rx_qp, it looks like for communicating with a peer, we use one QP for purely<br>   doing TX and one QP for purely doing RX (created on receipt of a CM REQ). That means for every peer we are connected to, we use two
<br>  QPs. Why not use a single QP for both TX and RX of data ? On receipt of a REQ from a peer or before trying to send data to peer,  we<br>  could possibly check if we already have a QP connection to the peer (by maintaining and looking up a QP and peer UD QPN + GID
<br> mapping) and then just use it. Or is it not as simple as that ?<br><br>  On a related note, the IPoIB CM RFC 4755, section 3.3 covers the case of simultaneous IB connection where REQs can cross paths.<br>  But the current implementation does not seem to handle this case. Is it because we create two QPs anyway and do not need to handle
<br>  this special case ?<br><br>2] In the ipoib_cm_rep_handler, the skbs seem to be dequeued and queued again. I am referring to the code below. What does this exactly  <br>   achieve ?<br><br>        skb_queue_head_init(&skqueue);
<br>        spin_lock_irq(&priv->lock);<br>        set_bit(IPOIB_FLAG_OPER_UP, &p->flags);<br>        if (p->neigh)<br>                while ((skb = __skb_dequeue(&p->neigh->queue)))<br>                        __skb_queue_tail(&skqueue, skb);
<br>        spin_unlock_irq(&priv->lock);<br>        while ((skb = __skb_dequeue(&skqueue))) {<br>                skb->dev = p->dev;<br>                if (dev_queue_xmit(skb))<br>                        ipoib_warn(priv, "dev_queue_xmit failed "
<br>                                   "to requeue packet\n");<br>        }<br><br>Thanks and Regards,<br>Amar<br>