[openib-general] gen2 dev branch

[Sean Hefty]

On Tue, 3 Aug 2004 06:56:33 +0300
"Yaron Haviv" <yaronh at voltaire.com> wrote:

> The current API doesn't deal with timeouts and retransmits, but leave
> that to the application as suggested in the pass, the benefit is that
> different apps can deal with retransmit differently. 

I think that the GSI needs to provide the timeout mechanism.  We don't want clients to have to re-implement this, and it makes it easier to match requests with responses.

> >QP redirection requires allocating ...  Because of the number of
> options available, I think that the user needs control over them.  
> 
> Agreed, a GSI server should own its redirected QP.

I don't think we're in agreement.  The client should control the redirected QPs, *not* the GSI.  Having the GSI control redirected QPs puts too much policy into the GSI.  I view the GSI as access to QP1 only.

> we need however to look at the redirect messages that run on QP1, when
> an active side sends a MAD and get a response that the MAD should be
> redirected, the MAD should be resent to the new QP, in the proposed
> implementation the GSI layer resends the MAD to the new QP when such
> redirect message arrives without involving the App, otherwise any
> consumer should have provided exactly the same functionality and its
> better to have it be transparent to the consumers.

I see no benefit to making redirection transparent.  The GSI is reducing control from the app, without having knowledge of what the client is trying to do.  The process of redirecting a remote node involves formatting and sending a MAD, so I don't see this as a win.

If something like this *is* necessary, then a "redirection layer" could be implemented on top of a simple layer-1 interface.

To be clear, I believe that the core GSI should operate on field values only, and let the meanings of those fields be defined by upper layers.  RMPP and request/response matching need to be generic modules that are available over any QP.  Clients should have control over redirection and redirected QPs.

I think that we need to examine the design of the APIs and the software architecture from a couple of perspectives to see that it can *best* meet all needs.  The CM doesn't require request/response matching or RMPP, and CM redirection is simple.  SA queries requires request/response matching and RMPP, and it's redirection is more complex.  Currently, I don't think that we're *best* meeting the needs of the CM.