> > > > I just read this section in the 1.2 version of the spec, and I still > > don't understand what the issue really is? 9.7.7.2 talks about IBA > > doing flow control based on the RECV WQEs posted. rping always ensures > > that there is a RECV posted before the peer can send. This is ensured > > by the rping protocol itself (see the comment at the front of rping.c > > describing the ping loop). > > > > I'm only ever sending one outstanding message via SEND/RECV. I would > > rather post exactly what is needed, than post some number of RECVs "just > > to be safe". Sorry if I'm being dense. What am I missing here? > > > > Steve. > > > > As far as I know, the credits are only updated by the ACK messages. > If there is a single work request outstanding on the RQ, > the ACK of the SEND message will have the credit field value 0 > (since exactly one receive WR was outstanding, and that is now consumed). > > As a result the remote side withh "think" that there are no > receive WQEs and will slow down (what spec refers to as limited WQE).
Oh. I understand now. This is an issue with only 1 RQ WQE posted and how IB tries to inform the peer transport of the WQE count. For iWARP, none of this transport-level flow control happens (and I'm more familiar with iWARP than IB). _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
