[openib-general] Re: RFC: e2e credits

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> 
> I did some spec reading to find this and found the following which I
> think makes the current requirement clear:
> 
> p.347 line 37 states "HCA receive queues must generate end-to-end
> credits (except for QPs associated with a SRQ), but TCA receive queues
> are not required to do so. This appears to be informative text. I first
> found the following:
> 
> p. 348 has the compliances for this for both HCAs and TCAs:
> 
> C9-150.2.1: For QPs that are not associated with an SRQ, each HCA re-
> ceive queue shall generate end-to-end flow control credits. If a QP is
> associated with an SRQ, the HCA receive queue shall not generate end-to-
> end flow control credits.
> 
> o9-95.2.1: Each TCA receive queue may generate end-to-end credits ex-
> cept for QPs that are associated with an SRQ. If a TCA supports SRQ, the
> TCA must not generate End-to-End Flow Control Credits for QPs associ-
> ated with an SRQ.
> 
> C9-151: If a TCA's given receive queue generates End-to-End credits,
> then the corresponding send queue shall receive and respond to those
> credits. This is a requirement on each send queue of a CA.
> 
> The above informative text also references the CA requirements in
> chapter 17 and on p. 1026 line 25 there is a row in the table for end to
> end flow control for RC consistent with the above. p.1028 has the
> compliances for this.

I know. You are saying HCA's will never have invalid code in AETH?
However we have this, towards the end of page 355.

----

"Even a responder which does generate end-to-end credits may choose to send
the 'invalid' code in the AETH"

----

This seems to imply that HCA (which must generate end-to-end credits)
may choose to send the 'invalid' code in the AETH?

What's your take on this?

-- 
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies