[openib-general] [PATCH] added comments to ib_mad.h - minor update

[Fab Tillier]

> From: Roland Dreier [mailto:roland.list at gmail.com]
> Sent: Sunday, August 08, 2004 9:26 AM
> 
> > If the GSI does not do the retries for the client, how do you handle the
> > case where the request times out but isn't retried before the response
> > comes
> > in?  In that case, the response no longer matches up to anything.  If it
> > gets dropped, the subsequent retry by the client could result in exactly
> > the
> > same result.  Will clients have a way to tell the GSI to keep a request
> > "active" for matching to receives between the time a send times out and
> > the client resends it?
> 
> I think if the response arrives after the request has timed out, the only
> sensible thing to do is discard it.  If the client is going to wait to
> retry after
> a timeout, and is willing to accept responses after the timeout, it seems
> that the client should have just used a longer timeout.

It's not that the client is going to wait, but rather that there is a period
of time between when the GSI times out a send and when a client receives
notification of such and can retry the send.  I'm concerned with any receive
coming in within that window.  It seems that the only client usage model is
to have no retries and a really long timeout.  Either that or the GSI has to
provide some synchronization to keep the send valid until the send callback
completes, but at the same time support the same MAD buffer to be resent by
the client from the callback.

I'm assuming that a send request by the client will get enqueued by the GSI
so that it may be matched against received responses.  The send needs to
stay in that queue until the client gives up on retries.  I'm just curious
as to how the current API is going to support this and what effect
supporting this has on API usage - i.e. can you retry a send from the send
completion callback, etc.

- Fab