Fwd: Re: [openib-general] static LID computationwithTS_HOST_DRIVER

[Yaron Haviv]

As I mentioned before, I think the best approach in the long run is to
have a well known Loopback LID

(that will stay as an alias also after the port changed its LID, not to
break apps), just like in any other stack 

 

>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 

 

It is also possible to leverage on APM (+ the SMI port change events) if
we don't want to deal with the HCA's

And in any case we want the apps to be able to recover from any RC
failures gracefully (not just LID changes)

 

Doing manual configuration on each host violates all the idea of zero
configuration and utility computing we all advocate for

 

Yaron

 

 

________________________________

From: openib-general-bounces at openib.org
[mailto:openib-general-bounces at openib.org] On Behalf Of Michael Krause
Sent: Friday, October 01, 2004 1:29 AM
To: openib-general at openib.org
Subject: Re: Fwd: Re: [openib-general] static LID
computationwithTS_HOST_DRIVER

 

At 03:40 PM 9/30/2004, David M. Brean wrote:



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.


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.  

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.




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.


Agreed.

Mike





-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.



_______________________________________________
openib-general mailing list
openib-general at openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20041001/794b9181/attachment.html>