[ofa-general] Understanding IPoIB-CM

Amar Mudrankit amar.mudrankit at gmail.com
Fri Aug 3 08:08:10 PDT 2007


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.

Please correct me if I am wrong, but based on my understanding of the code:

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
   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
  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
  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
 mapping) and then just use it. Or is it not as simple as that ?

  On a related note, the IPoIB CM RFC 4755, section 3.3 covers the case of
simultaneous IB connection where REQs can cross paths.
  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
  this special case ?

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
   achieve ?

        skb_queue_head_init(&skqueue);
        spin_lock_irq(&priv->lock);
        set_bit(IPOIB_FLAG_OPER_UP, &p->flags);
        if (p->neigh)
                while ((skb = __skb_dequeue(&p->neigh->queue)))
                        __skb_queue_tail(&skqueue, skb);
        spin_unlock_irq(&priv->lock);
        while ((skb = __skb_dequeue(&skqueue))) {
                skb->dev = p->dev;
                if (dev_queue_xmit(skb))
                        ipoib_warn(priv, "dev_queue_xmit failed "
                                   "to requeue packet\n");
        }

Thanks and Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20070803/efa667ac/attachment.html>


More information about the general mailing list