<br><br><div><span class="gmail_quote">On 8/5/07, <b class="gmail_sendername">Michael S. Tsirkin</b> <<a href="mailto:mst@dev.mellanox.co.il">mst@dev.mellanox.co.il</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Quoting Amar Mudrankit <<a href="mailto:amar.mudrankit@gmail.com">amar.mudrankit@gmail.com</a>>:<br>> Subject: Understanding IPoIB-CM<br>><br>><br>> I have been looking at the IPoIB CM code and have some queries. I'd greatly
<br>> 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
<br>> 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).<br>> 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<br>> 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
<br>> 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>Sure, this could work. One'd have to be sure to cover all error<br>cases though.
</blockquote><div><br>    So, there are two connections established between 2 communicating peers. 1 connection  each for transmitting in each direction. Is it correct?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>   On a related note, the IPoIB CM RFC 4755, section 3.3 covers the case of<br>> simultaneous IB connection where REQs can cross paths.<br>>   But the current implementation does not seem to handle this case. Is it
<br>> because we create two QPs anyway and do not need to handle<br>>   this special case ?<br><br>Yes.<br><br>> 2] In the ipoib_cm_rep_handler, the skbs seem to be dequeued and queued again.<br>> 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>This transmits all skbs.</blockquote><div><br>        Here, I wanted to ask  - before transmitting why is the skb->dev field  modified as the device is same IPoIB interface through which packets will be transmitted. Is p->dev is some other device? 
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">--<br>MST<br></blockquote></div><br>