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

[Sean Hefty]

>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 not sure that there's a real window here, and I agree with Roland.  The
client should have used a longer timeout.  The response in this case is just
discarded.  It didn't arrive within the specified timeout window -- for the
request that it was trying to match.  If the request is going to be resent
anyway, the client should resend the response, and hopefully, the timeout
window has been adjusted.

>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 think the difference in the models that you're talking about is whether a
timeout is: time to wait for a response from a specific request, time from
the first request multiplied by the number of retries to receive a response.
I think that either can work.

>i.e. can you retry a send from the send completion callback, etc.

I think allowing retries to be issued from the send completion callback
would be a requirement for the current API.