Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: Re: RFC: e2e credits > > On Sat, 2006-03-25 at 11:59, Michael S. Tsirkin wrote: > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > 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? > > > > > > Isn't it needed for when HCAs talk to TCAs which don't support E2E ? > > > > How so? This explicitly talks about responders that do support E2E. > > You're right. I misread it. So what's the issue relative to what was > being discussed about e2e credits or is this a separate question ?
Not sure I understand the question. The suggestion was to let ULP control on the responder side, whether to send valid credits in the AETH for the specific QP, and take the flow control bit in CM messages to mean whether the specific QP will have actual credits (1), or instead 'invalid credits'(0). This extends its meaning in the spec, which seems to speak about HCA-wide capability. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
