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