[openib-general] gen2 dev branch
yaronh at voltaire.com
Mon Aug 2 20:56:33 PDT 2004
On Tuesday, August 03, 2004 1:57 AM, Sean Hefty wrote:
> On Mon, 2 Aug 2004 16:35:05 -0700
> Roland Dreier <roland.list at gmail.com> wrote:
>> I don't really have a strong opinion, but I would lean towards having
>> basic handling of timeouts (just generating a callback when a timeout
>> happens) in the access layer.
> I agree. Looking at the propsed API, I don't see how timeouts are
> used currently. So, I think we want an API that does *not* do
> automatic retransmission, but does use a timeout when matching a
> response with request. This is probably easy enough to fix by adding
> a timeout to the MAD (GSI message?) structure.
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.
E.g. an app may want to send few MAD's and have a single timer for all,
instead of one per MAD, or have its own timer/retry policy
>From what I remember It does however match a response with a request and
issue a callback on a complete transaction (when a response to the MAD
arrived , rather than when the MAD was sent).
Maybe Todd or Hal/Moni can respond on how its done exactly
>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.
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.
More information about the general