<!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] SM Bad Port Handling</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi Hal,</FONT>
</P>
<P><FONT SIZE=2>Please see my comments below.</FONT>
</P>
<P><FONT SIZE=2>Eitan Zahavi</FONT>
</P>
<P><FONT SIZE=2>> Problem Statement:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Currently, OpenSM issues (directed route) SubnGet for NodeInfo and</FONT>
<BR><FONT SIZE=2>> NodeDescription to any node it finds. It then requests PortInfo for</FONT>
<BR><FONT SIZE=2>> each port which is physically up.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> There are scenarios where the port is physically up, but there is no</FONT>
<BR><FONT SIZE=2>> response to the SM get requests. In this case, the OpenSM keeps</FONT>
<BR><FONT SIZE=2>> retrying, never gives up, and doesn't service anything else in the</FONT>
<BR><FONT SIZE=2>> subnet (I'm not 100% positive on this last point).</FONT>
<BR><FONT SIZE=2>[EZ] I have never seen this! Are you sure about it? Are you sure we are talking about gen1 ported to gen2?</FONT>
</P>
<P><FONT SIZE=2>What will happen in a case of non responding port is that OpenSM will retry the send (actually the lower level does it) for the number of retries OpenSM is configured to use (actually 4 times) and then ignore the port and everything behind it. The reported topology (on stdout) will have the word UNKNOWN on the remote side of the link this port connects to.</FONT></P>
<P><FONT SIZE=2>I will be happy to see a log file that shows what you claim happens. Or even if you can explain to me how and where in the code causes that. </FONT></P>
<P><FONT SIZE=2>I have been checking the way OpenSM handles irresponsive ports during the the last two weeks, and did not see such case.</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Assumption:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The proposed solution assumes that the ignore GUIDs file option of</FONT>
<BR><FONT SIZE=2>> OpenSM only impacts the routing algorithm (path counting) and should not</FONT>
<BR><FONT SIZE=2>> be extended for bad port handling.</FONT>
<BR><FONT SIZE=2>[EZ] This is correct.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Proposed Solution:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> The OpenSM will implement a configurable policy (some number of</FONT>
<BR><FONT SIZE=2>> consecutive lack of responses to SM requests). At the point of</FONT>
<BR><FONT SIZE=2>> exhaustion of the timeout/retry strategy, that port will be marked as</FONT>
<BR><FONT SIZE=2>> "bad" by OpenSM.</FONT>
<BR><FONT SIZE=2>[EZ] This is already the current behavior. Nothing should be done.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> At this point, should it attempt to revive the port by bringing the</FONT>
<BR><FONT SIZE=2>> physical link down and back up ? Should it try this several times before</FONT>
<BR><FONT SIZE=2>> declaring the port as "bad" ? In any case, this is a refinement on the</FONT>
<BR><FONT SIZE=2>> basic strategy for dealing with this scenario.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Also, there could also be a periodic "ping" at a slower rate to check if</FONT>
<BR><FONT SIZE=2>> the "bad" ports revive.</FONT>
<BR><FONT SIZE=2>[EZ] This will be released in gen1 within 2 weeks or so. The enhancement to light sweep will include the irresponsive ports in the light sweep. Once they respond a new heavy sweep will be generated.</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> A "bad" port per this scenario still maintains its LID and other state.</FONT>
<BR><FONT SIZE=2>> OpenSM will indicate a "bad" port detected via an internal port physical</FONT>
<BR><FONT SIZE=2>> state which it will set to down. The "real" port physical state will be</FONT>
<BR><FONT SIZE=2>> reflected accurately inside OpenSM.</FONT>
<BR><FONT SIZE=2>[EZ] It is better to use the "un-healthy" bit of the physical port - which OpenSM is already maintaining.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Once a "bad" port is detected, it will no longer be polled and the</FONT>
<BR><FONT SIZE=2>> routing algorithm should be invoked to route around this.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Is there a need to store these "bad" ports persistently (and ignore them</FONT>
<BR><FONT SIZE=2>> on startup) ?</FONT>
<BR><FONT SIZE=2>[EZ] No I do not think so.</FONT>
<BR><FONT SIZE=2>> </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>