[openib-general] RMPP and timeouts/retries

[Sean Hefty]

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

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

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

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

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

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.

- Sean