[openib-general] Re: [PATCH] [RFC] - example user moderdmaping/pongprogram using CMA

[Steve Wise]

> > 
> > 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).