<html>
<body>
<font size=3>At 03:40 PM 9/30/2004, David M. Brean wrote:<br>
<blockquote type=cite class=cite cite="">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.</font></blockquote><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>
<blockquote type=cite class=cite cite=""><font size=3>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.</font></blockquote><br>
Agreed.<br><br>
Mike<br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>-David<br><br>
Roland Dreier wrote:<br>
<blockquote type=cite class=cite cite="">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.<br>
</blockquote><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></font></blockquote></body>
</html>