<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [openib-general] RMPP and timeouts/retries</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi Sean,</FONT>
</P>
<P><FONT SIZE=2>This seems very nice. Thank you.</FONT>
<BR><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>Eitan Zahavi</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Sean Hefty [<A HREF="mailto:sean.hefty@intel.com">mailto:sean.hefty@intel.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Wednesday, June 08, 2005 8:05 AM</FONT>
<BR><FONT SIZE=2>> To: 'Hal Rosenstock'; Sean Hefty</FONT>
<BR><FONT SIZE=2>> Cc: openib-general@openib.org</FONT>
<BR><FONT SIZE=2>> Subject: RE: [openib-general] RMPP and timeouts/retries</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> >> I'm having some trouble using timeouts and retries with RMPP. The issue</FONT>
<BR><FONT SIZE=2>> >> I see is that what constitutes a response is different than normal MADs</FONT>
<BR><FONT SIZE=2>> >> for RMPP. With the current "definition" of response, is the</FONT>
<BR><FONT SIZE=2>> >> timeout/retry only usable on the SA client side where the normal</FONT>
<BR><FONT SIZE=2>> >> definition is more closely followed ? If so, is there still an issue</FONT>
<BR><FONT SIZE=2>> >> with SA GetTable as the initial request is not RMPP ?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The SA client should set the timeout > 0 to indicate that a response MAD is</FONT>
<BR><FONT SIZE=2>> expected. It can set retries, but isn't required to do so.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> >Is the response not at the RMPP level ? So a response would be for dual</FONT>
<BR><FONT SIZE=2>> >ended RMPP ?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Request/response is separate from RMPP. Request/response is defined at the</FONT>
<BR><FONT SIZE=2>> message level from the viewpoint of the user of the MAD layer. (I.e. is the</FONT>
<BR><FONT SIZE=2>> response bit set in the MAD header, regardless of the size of the MAD.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Setting timeout > 0 when sending indicates that a MAD should be received with</FONT>
<BR><FONT SIZE=2>> the response bit set that is in reply to the request. If timeout = 0 but RMPP</FONT>
<BR><FONT SIZE=2>> is marked active, the MAD will still invoke RMPP and not complete until all</FONT>
<BR><FONT SIZE=2>> segments have been ACKed. (I.e. the completion of an RMPP send indicates that</FONT>
<BR><FONT SIZE=2>> the MAD was received.)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Retries is a little more complex. It indicates the number of times to send a</FONT>
<BR><FONT SIZE=2>> request in hopes of receiving a response (if one is expected) or an ACK (if</FONT>
<BR><FONT SIZE=2>> using RMPP).</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> >> On the SA side, there does not appear to be a way to use this feature.</FONT>
<BR><FONT SIZE=2>> >> Is that correct ?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> For the SA side responding to a request, you would want to set retries > 1, but</FONT>
<BR><FONT SIZE=2>> timeout = 0. Timeout of 0 indicates that no response is expected, since the SA</FONT>
<BR><FONT SIZE=2>> is sending the response. Having a retry count would allow a retransmission if</FONT>
<BR><FONT SIZE=2>> an ACK were lost.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> You should be able to mix RMPP and non-RMPP MADs without restriction: non-</FONT>
<BR><FONT SIZE=2>> RMPP</FONT>
<BR><FONT SIZE=2>> request - RMPP response, RMPP request - non-RMPP response, RMPP request and</FONT>
<BR><FONT SIZE=2>> response, non-RMPP request and response. If one of these conditions doesn't</FONT>
<BR><FONT SIZE=2>> work, then there's a bug in the code. I'm pretty sure that I tested all of</FONT>
<BR><FONT SIZE=2>> these combinations, but that doesn't mean that it won't hit a bug talking with</FONT>
<BR><FONT SIZE=2>> another RMPP implementation.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> - Sean</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> _______________________________________________</FONT>
<BR><FONT SIZE=2>> openib-general mailing list</FONT>
<BR><FONT SIZE=2>> openib-general@openib.org</FONT>
<BR><FONT SIZE=2>> <A HREF="http://openib.org/mailman/listinfo/openib-general" TARGET="_blank">http://openib.org/mailman/listinfo/openib-general</A></FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> To unsubscribe, please visit <A HREF="http://openib.org/mailman/listinfo/openib-general" TARGET="_blank">http://openib.org/mailman/listinfo/openib-general</A></FONT>
</P>
</BODY>
</HTML>