Fwd: Re: [openib-general] static LID computation withTS_HOST_DRIVER

David M. Brean David.Brean at Sun.COM
Thu Sep 30 15:40:02 PDT 2004


The IBA provides two mechanisms for updating subnet management data:

1) through the verbs - see Modify HCA (section 11.2.1.3)
2) through Subnet management packets (SMPs) - see Subnet Management
Class (section 14.2)

The IBA only supports updating the LID via SMPs (#2 above) and an entity
using SMPs must have the M_Key.  If that entity doesn't have the M_Key,
then it can't reliably change the LID.

In addition, the IBA allows an endnode to request, through the verbs
interface provided for the "node reinitialization" (see 14.4.4)
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 :)).

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.

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.

-David

Roland Dreier wrote:
>I don't see anything in the spec that forbids a CA from having an
>arbitrary value in PortInfo:LID after initialization but before the SM
>discovery (please correct me if I missed something).  I also don't see
>anything that forbids an SM implementation from providing a mechanism
>for preserving the LIDs it finds or administratively assigning LIDs.
>
>Of course none of this is required but I don't see a problem with
>allowing it.
>





More information about the general mailing list