> +static int iwch_process_mad(struct ib_device *ibdev,
> + int mad_flags,
> + u8 port_num,
> + struct ib_wc *in_wc,
> + struct ib_grh *in_grh,
> + struct ib_mad *in_mad, struct ib_mad *out_mad)
> +{
> + PDBG("%s:%s:%u\n", __FILE__, __FUNCTION__, __LINE__);
> + return -ENOSYS;
> +}
I'd rather fix the core so that this function (and all the other
-ENOSYS stubs) never get called, rather than forcing low-level drivers
to provide stubs. How hard is that to do?
> + /*
> + * Attempt to make the CQ big enough to handle the T3
> + * additional CQE possibilities:
> + * TERMINATE,
> + * 2 CQES for each RDMA READ operation,
> + * incoming RDMA READ REQUEST FAILUREs
> + * We can make the CQ big enough to handle these for
> + * a single QP. But problems can arise if the CQ is shared...
> + */
Is there a plan for how to handle this? It seems really bad that a
consumer could create a CQ that it thinks is big enough to handle all
the outstanding work requests that it might post, but then still have
the CQ overrun because of internal implementation details.
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
