<html>
<body>
<font size=3>At 11:35 AM 2/8/2006, Steve Wise wrote:<br><br>
<blockquote type=cite class=cite cite="">> > <br>
> > I just read this section in the 1.2 version of the spec, and I
still<br>
> > don't understand what the issue really is? 9.7.7.2 talks
about IBA<br>
> > doing flow control based on the RECV WQEs posted. rping always
ensures<br>
> > that there is a RECV posted before the peer can send.
This is ensured<br>
> > by the rping protocol itself (see the comment at the front of
rping.c<br>
> > describing the ping loop).<br>
> > <br>
> > I'm only ever sending one outstanding message via
SEND/RECV. I would<br>
> > rather post exactly what is needed, than post some number of
RECVs "just<br>
> > to be safe". Sorry if I'm being dense. What am
I missing here?<br>
> > <br>
> > Steve.<br>
> > <br>
> <br>
> As far as I know, the credits are only updated by the ACK
messages.<br>
> If there is a single work request outstanding on the RQ,<br>
> the ACK of the SEND message will have the credit field value 0<br>
> (since exactly one receive WR was outstanding, and that is now
consumed).<br>
> <br>
> As a result the remote side withh "think" that there are
no<br>
> receive WQEs and will slow down (what spec refers to as limited
WQE).<br><br>
Oh. I understand now. This is an issue with only 1 RQ WQE
posted and<br>
how IB tries to inform the peer transport of the WQE count. For
iWARP,<br>
none of this transport-level flow control happens (and I'm more
familiar<br>
with iWARP than IB).</blockquote><br>
For iWARP, we decided to not implement application receiver based flow
control due to two items:TCP provides transport-level flow control (IB
does not provide the equivalent per se) and upon examination of the
majority of the ULP, they exchange and track the number of receive
buffers allowed to be processed thus there is no need to replicate this
in iWARP. There are some subtleties as well between a message-based
transport and a byte stream such as TCP that go into the equation but
these are not that important for most application writers to deal
with.<br><br>
Mike</font></body>
</html>