>> 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
