[openib-general] Some ib_mad.h Redirection Comments

[Hal Rosenstock]

On Thu, 2004-08-05 at 11:40, Sean Hefty wrote:
> On Thu, 05 Aug 2004 09:03:47 -0400
> Hal Rosenstock <halr at voltaire.com> wrote:
> 
> Obviously, I haven't thought through all of the details on this, so some discussion is good.
> 
> > Does ib_mad_qp_redir need to take a ib_mad_reg_req parameter or at least
> > a GS class ?
> 
> I don't think it's necessary.  The ib_mad_reg_req is used to route unsolicited MADs to the proper client.  Since the user has control over the QP and CQ in the redirected case, they receive all MADs on the QP that they are redirecting to.
>  
> > How is the redirection information in a GS agent's ClassPortInfo filled
> > in ? Is this part of what register and redirection (maybe a different
> > one from what is proposed) should handle ? The redirection can occur to
> > a remote QP, not just a QP on the local node.
> 
> I was assuming that the client would format (maybe with help) and send the redirection message.  Redirection messages, therefore, would flow from client to client.  If a simpler redirection interface were desired, it could be built on top of the proposed APIs, but I think that that could be above the access layer.

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 ?

The only other case is when it is being redirected outside the local
node which does not appear to be supported.

> > In terms of a GS entity making requests (which have responses), if it is
> > redirected, will the retransmission to the redirected location occur
> > without consumer intervention ?
> 
> I was assuming not.  Since redirection comes as a response to a request, my thought was to complete the request as redirected.  (Maybe we can add another completion status value.)  It should be fairly simple for the client to re-issue the send to the redirected QP.  The benefit of this is that the client can automatically send future requests to the redirected QP.

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.

In terms of not supporting remote redirection, this might be an
important feature for scaling. I suppose we can always cross that
one when we get there.

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.

-- Hal