Quoting r. Steve Wise <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] Re: [PATCH] [RFC] - example user > moderdmaping/pongprogram using CMA > > On Wed, 2006-02-08 at 19:10 +0200, Michael S. Tsirkin wrote: > > Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > > > Subject: RE: [openib-general] Re: [PATCH] [RFC] - example user mode > > > rdmaping/pongprogram using CMA > > > > > > >Steve, looks like you have at most a single receive work request posted > > > >at the > > > >receive workqueue at all times. > > > >If true, this is *really* not a good idea, performance-wise, even if you > > > >actually have at most 1 packet in flight. > > > > > > Can you provide some more details on this? > > > > See 9.7.7.2 end-to-end (message level) flow control > > > > 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). -- 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
