[ofa-general] IPOIB CM (NOSRQ)[PATCH V3] patch for review

Pradeep Satyanarayana pradeep at us.ibm.com
Thu May 3 17:12:42 PDT 2007


Thanks for the review. Some of them MST had already pointed out. I will 
respond to the additional ones that you make.

Pradeep
pradeep at us.ibm.com

Roland Dreier <rdreier at cisco.com> wrote on 05/03/2007 12:01:03 PM:

>  > +#define IPOIB_CM_OP_NOSRQ (1ul << 29)
> 
> I don't understand the point of this... the only places you do anything
> with it are:
> 
>  > +       priv->cm.rx_wr.wr_id = wr_id << 32 | index | 
IPOIB_CM_OP_NOSRQ;
>  > +       index = (wc->wr_id & ~IPOIB_CM_OP_NOSRQ) & NOSRQ_INDEX_MASK ;
>  > +       if ((wc->wr_id & IPOIB_CM_OP_SRQ) || (wc->wr_id & 
> IPOIB_CM_OP_NOSRQ))
> 
> so probably the most sensible thing to do is just to rename
> IPOIB_CM_OP_SRQ to IPOIB_OP_CM_RECV.

Agreed.

> 
>  > +/* These two go hand in hand */
>  > +#define NOSRQ_INDEX_RING_SIZE 1024
>  > +#define NOSRQ_INDEX_MASK      0x00000000000003ff
> 
> Rather than having a comment, I would just do
> 
> #define NOSRQ_INDEX_RING_SIZE 1024
> #define NOSRQ_INDEX_MASK      (NOSRQ_INDEX_RING_SIZE - 1)
> 
> also I think the RING name is wrong -- it's not a ring, it's a table,
> right?  I don't like having a static limit on the number of nosrq
> connections; could this be a hash table instead?
> 

I will just call this an array. Nosrq will hog memory and my thought was 
that 1024 was pretty large. I envisioned using nosrq for a small number 
(maybe a 
few dozen), and so did not think it was necessary to make this a module 
paramater 
either. What do you suggest? 

> 
>  > -       rep.srq = 1;
> 
>  > +       if (priv->cm.srq)
>  > +               rep.srq = 1;
>  > +       else
>  > +               rep.srq = 0;
> 
> similarly I would rather see "rep.srq = !!priv->cm.srq"

ok

> 
>  > +       /* Allocate space for the rx_ring here */
>  > +       p->rx_ring = kzalloc(ipoib_recvq_size * sizeof *p->rx_ring,
>  > +                            GFP_KERNEL);
> 
> 
>  > +               printk(KERN_WARNING "NOSRQ supports a max of %d RC "
>  > +                      "QPs. That limit has now been reached\n",
>  > +                      NOSRQ_INDEX_RING_SIZE);
> 
> ipoib_warn() instead of printk?  Also isn't this going to flood logs
> if the remote side keeps trying to connect?

As you describe, the remote side will continue to attempt connecting and
will fail. That is a pretty serious scenario. Hence I leaned towards 
flooding
the logs rather than losing this among a ton of other messages, there may 
be
application speceific messages too. I can change this to ipoib_warn().

> 
>  > +       ret = ipoib_cm_modify_rx_qp(dev, cm_id, p->qp, psn);
>  > +       if (ret) {
>  > +               ipoib_warn(priv, "ipoib_cm_modify_rx_qp() failed 
%d\n", 
>  > ret);
>  > +               goto err_modify_nosrq;
>  > +       }
> 
> It's good to goto to unwind code, but in this case you just have a
> return at err_modify_nosrq -- why not just return directly?  However
> you seem to leak rx_ring here, so it would be better to use the unwind
> code more consistently instead of using return later.

Yes, there is a leak here -will fix that.

                     kfree(p->rx_ring);
>  > +                       return -ENOMEM;
>  > +               }
>  > +
>  > +               /* Can we call the nosrq version? */
>  > +               if (ipoib_cm_post_receive(dev, i << 32 | index)) {
>  > +                       ipoib_warn(priv, "ipoib_ib_post_receive "
>  > +                                  "failed for  buf %d\n", i);
>  > +                       ipoib_cm_dev_cleanup(dev);
> 
> seems like you're missing the call to kfree(p->rx_ring) here?
> this code could probably benefit from a goto to unwind code.

Yes there is leak here too -will fix.




More information about the general mailing list