<html>
<body>
<font size=3>At 03:31 AM 3/24/2006, Hal Rosenstock wrote:<br>
<blockquote type=cite class=cite cite="">On Thu, 2006-03-23 at 12:34,
Michael S. Tsirkin wrote:<br>
> Quoting r. Hal Rosenstock <halr@voltaire.com>:<br>
> > > > > > > > > >Sean, just to wrap it
up, the API at the verbs layer will look<br>
> > > > > > > > > >like the below, and then
ULPs just put the value they want in<br>
> > > > > > > > > >the CM and CM will pass
it in to low level.<br>
> <br>
> So this is our question, right?<br>
> <br>
> <br>
> CM REQ and REP messages include the following field:<br>
> <br>
> ---------------<br>
> 12.7.26 END-TO-END FLOW CONTROL<br>
> Signifies whether the local CA actually implements End-to-End Flow
Control<br>
> (1), or instead always advertises .invalid credits.(0). See
section<br>
> 9.7.7.2 End-to-End (Message Level) Flow Control for more
detail.<br>
> ---------------<br>
> <br>
> Consider and implementation that advertises valid credits for<br>
> connections, and always advertises invalid credits for other
connections.<br>
> This is compliant since the IB spec says (end-to-end (message level)
flow<br>
> control, Requester Behaviour):<br>
> "Even a responder which does generate end-to-end credits may
choose to send the<br>
> 'invalid' code in the AETH"<br><br>
I did some spec reading to find this and found the following which I<br>
think makes the current requirement clear:<br><br>
p.347 line 37 states "HCA receive queues must generate
end-to-end<br>
credits (except for QPs associated with a SRQ), but TCA receive
queues<br>
are not required to do so. This appears to be informative text. I
first<br>
found the following:<br><br>
p. 348 has the compliances for this for both HCAs and TCAs:<br><br>
C9-150.2.1: For QPs that are not associated with an SRQ, each HCA
re-<br>
ceive queue shall generate end-to-end flow control credits. If a QP
is<br>
associated with an SRQ, the HCA receive queue shall not generate
end-to-<br>
end flow control credits.<br><br>
o9-95.2.1: Each TCA receive queue may generate end-to-end credits
ex-<br>
cept for QPs that are associated with an SRQ. If a TCA supports SRQ,
the<br>
TCA must not generate End-to-End Flow Control Credits for QPs
associ-<br>
ated with an SRQ.<br><br>
C9-151: If a TCA's given receive queue generates End-to-End credits,<br>
then the corresponding send queue shall receive and respond to those<br>
credits. This is a requirement on each send queue of a CA.<br><br>
The above informative text also references the CA requirements in<br>
chapter 17 and on p. 1026 line 25 there is a row in the table for end
to<br>
end flow control for RC consistent with the above. p.1028 has the<br>
compliances for this.<br><br>
> Is it compliant for CM implementations to set/clear the End-to-End
Flow Control<br>
> field accordingly, taking it to mean<br>
> <br>
> "whether the local CA actually implements End-to-End Flow
Control<br>
> (1), or instead always advertises 'invalid credits'(0)"<br>
> *for the specific connection*<br><br>
So IMO the intent of what was written is clear (on a per CA basis)
and<br>
this is a spec change which is OK to propose but needs a different<br>
writeup.</blockquote><br>
The spec was written to minimize the impact to TCA in terms of e2e
credits. HCA are expected to use e2e credits all the time sans SRQ
which is a special multiplexing case where e2e isn't that beneficial /
logical to support. Each connection must negotiate this per CA pair
as no single policy was deemed practical across all usage
models. I don't think there would be much support for
changing the spec.<br><br>
BTW, iWARP does not support e2e credits as it relies upon the ULP to
advertise and track its buffer usage. It was therefore deemed
unnecessary.<br><br>
Mike</font></body>
</html>