[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