Hi Sean,
This seems very nice. Thank you.
The only thing I dislike in this API is the "implicit" behavior. I would prefer a clear flag saying - is_response_expected. Rather than the timeout to flag this. But this is a matter of taste not functionality.
Eitan Zahavi
> -----Original Message-----
> From: Sean Hefty [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 08, 2005 8:05 AM
> To: 'Hal Rosenstock'; Sean Hefty
> Cc: [email protected]
> Subject: RE: [openib-general] RMPP and timeouts/retries
>
> >> 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
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
