[openib-general] Some ib_mad.h Redirection Comments

[Sean Hefty]

On Thu, 05 Aug 2004 17:36:58 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

> If the class were also provided when the QP was redirected above,
> wouldn't all the information be available to issue the redirect from
> when a request came in ?

Having the access layer send the redirect response prevents the client from redirecting to different QPs.  See line 27 of page 667: "It is permissible for different requesters...to be redirected to a different interface."  This is why I think we want to move the redirection above the lowest level APIs.
 
> The only other case is when it is being redirected outside the local
> node which does not appear to be supported.

This is supported.  The API assumes that the the client formats and sends the redirect response.  The purpose behind the ib_mad_qp_redir() routine is to "attach" MAD processing to a user allocated QP.  The struct ib_qp* parameter into that routine may not be needed, but could be useful depending on the implementation.

I could have made myself clearer by adding a IB_WC_REDIR_RESP to ib_wc for the send completion.


> See my previous email on the two cases. Redirection could be deferred to
> the next request which is what you are proposing but I think I would
> want to look at the implementation complexity before committing to that.

My initial thought is to have the redirection occur immediately.  Any RMPP in progress is simply aborted, and the send is retransmitted.  I don't think we need to worry about trying to optimize redirecting in the middle of RMPP, since it doesn't seem like a sane thing to try to do anyway.
 
> There is one other aspect of redirection that should be discussed.
> Should the redirection location be cached ? That seems like a good thing
> to me as it saves on additional redirects to get to the new location.

The client would be responsible for caching the redirection.