[openib-general] [PATCH 03/18] [RFC] Provider Registration and Methods

Roland Dreier rdreier at cisco.com
Tue Mar 7 12:56:11 PST 2006


 > +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.



More information about the general mailing list