<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>As I mentioned before, I think the best
approach in the long run is to have a well known Loopback LID<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>(that will stay as an alias also after the
port changed its LID, not to break apps), just like in any other stack <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>From a short research I did once I think
it is possible to create one even in the current Mellanox HW leveraging on the
Multicast support with little firmware changes, maybe Mellanox can comment on
that <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>It is also possible to leverage on APM (+
the SMI port change events) if we don’t want to deal with the HCA’s<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>And in any case we want the apps to be
able to recover from any RC failures gracefully (not just LID changes)<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Doing manual configuration on each host
violates all the idea of zero configuration and utility computing we all advocate
for<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Yaron<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
openib-general-bounces@openib.org [mailto:openib-general-bounces@openib.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Michael Krause<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, October 01, 2004
1:29 AM<br>
<b><span style='font-weight:bold'>To:</span></b> openib-general@openib.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: Fwd: Re:
[openib-general] static LID computationwithTS_HOST_DRIVER</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>At 03:40 PM 9/30/2004, David M. Brean wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>The IBA provides two mechanisms for updating subnet management data:<br>
<br>
1) through the verbs - see Modify HCA (section 11.2.1.3)<br>
2) through Subnet management packets (SMPs) - see Subnet Management<br>
Class (section 14.2)<br>
<br>
The IBA only supports updating the LID via SMPs (#2 above) and an entity<br>
using SMPs must have the M_Key.  If that entity doesn't have the M_Key,<br>
then it can't reliably change the LID.<br>
<br>
In addition, the IBA allows an endnode to request, through the verbs<br>
interface provided for the "node reinitialization" (see 14.4.4)<br>
mechanism, that subnet management state, such as the LID, be preserved, when a
port transitions through the DOWN state.  However, the SM may not honor
that request so the endnode must handle that possibility because LID assignment
policy is owned by the SM.  Furthermore, this mechanism is used on ports
that have previously been initialized by the SM (maybe that's why it's called
the reinitialization function :)).<br>
<br>
Given the mechanisms in the specification, I think that its possible to have IB
clients use loopback, even under the endnode power-up scenario, while the port
is not in the ACTIVE state and have them continue without disruption when the
port is made ACTIVE on the subnet by the SM with use of the reinitialization
mechanism.  This is a very useful mechanism for various failover
situations.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
This is a reasonable approach where the loopback LID being used is updated upon
the port being initialized (akin to solving this in the CI but still allowing
CM to work with a known LID.  It avoids any complexity in the SM having to
preserve LID that may not be optimal or potentially unique within the
subnet.  <br>
<br>
Not sure this might work but it seems to me that APM mech could be used to
configure a new configured LID and then transfer the connection to the
configured.  May take a bit of work in CM as APM is nominally set up
during these exchanges.<br>
<br>
<br>
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>There is no current IBA mechanism or protocol for an endnode to set
just the LID, even if it had the M_Key, and have the SM preserve that value.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
Agreed.<br>
<br>
Mike<br>
<br>
<br>
<br>
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>-David<br>
<br>
Roland Dreier wrote:<br>
<br>
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I don't see anything in the spec that forbids a CA from having an<br>
arbitrary value in PortInfo:LID after initialization but before the SM<br>
discovery (please correct me if I missed something).  I also don't see<br>
anything that forbids an SM implementation from providing a mechanism<br>
for preserving the LIDs it finds or administratively assigning LIDs.<br>
<br>
Of course none of this is required but I don't see a problem with<br>
allowing it.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
<br>
_______________________________________________<br>
openib-general mailing list<br>
openib-general@openib.org<br>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora=autourl>http://openib.org/mailman/listinfo/openib-general</a><br>
<br>
To unsubscribe, please visit <a
href="http://openib.org/mailman/listinfo/openib-general" eudora=autourl>http://openib.org/mailman/listinfo/openib-general</a><o:p></o:p></span></font></p>

</div>

</div>

</body>

</html>