[openib-general] RMPP and timeouts/retries

[Hal Rosenstock]

On Wed, 2005-06-08 at 01:04, Sean Hefty wrote:
> >> I'm having some trouble using timeouts and retries with RMPP. The issue
> >> I see is that what constitutes a response is different than normal MADs
> >> for RMPP. With the current "definition" of response, is the
> >> timeout/retry only usable on the SA client side where the normal
> >> definition is more closely followed ? If so, is there still an issue
> >> with SA GetTable as the initial request is not RMPP ?
> 
> The SA client should set the timeout > 0 to indicate that a response MAD is
> expected.  It can set retries, but isn't required to do so.

OK.

> >Is the response not at the RMPP level ? So a response would be for dual
> >ended RMPP ?
> 
> Request/response is separate from RMPP.  Request/response is defined at the
> message level from the viewpoint of the user of the MAD layer.  (I.e. is the
> response bit set in the MAD header, regardless of the size of the MAD.)

Understood. It's method based (response bit and trap repress).

> Setting timeout > 0 when sending indicates that a MAD should be received with
> the response bit set that is in reply to the request.  If timeout = 0 but RMPP
> is marked active, the MAD will still invoke RMPP and not complete until all
> segments have been ACKed.  (I.e. the completion of an RMPP send indicates that
> the MAD was received.)

If timeout = 0, does RMPP still indicate a timeout if an ACK is lost and
the other end does not reACK ?

> Retries is a little more complex.  It indicates the number of times to send a
> request in hopes of receiving a response (if one is expected) or an ACK (if
> using RMPP).

Any effect on ABORT and/or STOP ?

> >> On the SA side, there does not appear to be a way to use this feature.
> >> Is that correct ?
> 
> For the SA side responding to a request, you would want to set retries > 1, but
> timeout = 0.  Timeout of 0 indicates that no response is expected, since the SA
> is sending the response.  Having a retry count would allow a retransmission if
> an ACK were lost.

I will try that. Using retry and timeout on the SA side is definitely
problematic. Right now it is set to no retries and no timeout on the SA
side. I will change and retest.

> You should be able to mix RMPP and non-RMPP MADs without restriction: non-RMPP
> request - RMPP response, RMPP request - non-RMPP response, RMPP request and
> response, non-RMPP request and response.  If one of these conditions doesn't
> work, then there's a bug in the code.  I'm pretty sure that I tested all of
> these combinations, but that doesn't mean that it won't hit a bug talking with
> another RMPP implementation.

The main new one right now is non RMPP request - RMPP response. SA does
not currently support any of the dual sided RMPP methods (so there is no
RMPP request - RMPP response). (Non RMPP request - non RMPP response is
what is mainly used). I'm not sure the other combination has a use.

Thanks.

-- Hal