[openib-general] Re: Re: RFC: e2e credits

[Sean Hefty]

Michael S. Tsirkin wrote:
>>The only way I can find for consumers to make use of this value is for them 
>>to change their algorithms based on whether flow control is supported or 
>>not.  But it's not clear to me how the consumer determines what value to 
>>set flow control to.
> 
> Oh, if you always post receive WQE before remote side posts send WQEs, then
> you can disable flow control. SDP does this.

But as you're trying to address, there's no way to disable flow control.  I.e. 
this value doesn't get associated with the QP.  So, currently, the only use that 
this value has is for the ULP to change its algorithm based on whether or not 
it's set.

My interpretation of the spec is that the value carried in the CM message 
applies to the HCA as a whole, such that all REQs originating from the same HCA 
should have the same value.  But I don't see how to determine what that value 
should be.

>>>>9.7.7.2.4 
>>>>
>>>>Even a responder which does generate end-to-end credits may choose
>>>>to send the 'invalid' code in the AETH.
> 
> 
> So an application can't really depend on the e2e credits for correctness -
> its just an optimization hint.

Okay - I'm confused now.  Why have this value at all?  How does the statement 
above match up with C9-150.2.1: For QPs that are not associated with an SRQ, 
each HCA receive queue shall generate end-to-end flow control credits?

> Anyway, sine ULPs don't seem to need it, another approach would be an option to
> disable these flow controls globally, and probably add a module option to enable
> them back just in case.  That's much simpler, isn't it?
> 
> What do you think?

Examining the spec, it looks like flow control is defined as a per HCA feature. 
  Do we need an ib_device_cap_flag to indicate if flow control is enabled or not 
on the device?

- Sean