[openib-general] Some ib_mad.h Redirection Comments

[Hal Rosenstock]

On Thu, 2004-08-05 at 16:56, Sean Hefty wrote:
> 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.

Are you talking about a client with multiple QPs and causing the
requester to alternate amongst them via some (client) load balancing
algorithm ? 

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

I don't think this by itself forces redirection above the API. I think
it can still be handled transparently inside the GSI.

I'm also not quite sure what a requester is in this context (and this is
informative rather than normative (compliance) text). 

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

I think this depends on what the meaning of calling qp_redir is/should
be. I think we still have differing assumptions about this.

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

This seems like a commonality which can be pushed down into the access
layer and makes more sense when the access layer is handling the
retransmissions on redirect. If it isn't, it makes less sense.

So back to that issue: if the access layer is already matching responses
to requests (when timeout is enabled), I don't see why it doesn't handle
the retransmission on receipt of redirect so each client doesn't need to
implement this.

-- Hal