[ofa-general] [PATCH] [RFC] IPOIB/CM Enable SRQ support on HCAs with less than 16 SG entries

Roland Dreier rdreier at cisco.com
Thu Dec 20 17:50:37 PST 2007


 > +static int num_of_frags;
 > +int max_cm_mtu;

I think these values need to be per-interface -- think of the case of
a system with more than one type of HCA installed, where the different
HCAs have different limits.

 > @@ -623,6 +626,7 @@ repost:
 >  			--p->recv_count;
 >  			ipoib_warn(priv, "ipoib_cm_post_receive_nonsrq failed "
 >  				   "for buf %d\n", wr_id);
 > +		kfree(mapping); /*** Check if this needed ***/

This looks really bogus -- I don't see anything in your patch that
changes mapping from being allocated on the stack.

 > +	if (ipoib_cm_has_srq(dev)) {
 > +		ret = ib_query_srq(priv->cm.srq, &srq_attr);
 > +		if (ret) {
 > +			printk(KERN_WARNING "ib_query_srq() failed with %d\n", ret);
 > +			return -EINVAL;
 > +		}
 > +		/* pad similar to IPOIB_CM_MTU */
 > +		max_cm_mtu = srq_attr.max_sge * PAGE_SIZE - 0x10;
 > +		num_of_frags = srq_attr.max_sge;
 > +		ipoib_dbg(priv, "max_cm_mtu = 0x%x, num_of_frags=%d\n",
 > +			  max_cm_mtu, num_of_frags);
 > +	} else {
 > +		max_cm_mtu = IPOIB_CM_MTU;
 > +		num_of_frags  = IPOIB_CM_RX_SG;
 > +	}

I think in the SRQ case you still want to make sure num_of_frags is no
more than IPOIB_CM_RX_SG.  And if we're going to check the SRQ scatter
capabilities, we should probably add the same thing for the non-SRQ
case to make sure we don't exceed what QP receive queues can handle.



More information about the general mailing list