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

[Michael Krause]

At 05:09 PM 9/29/2004, Roland Dreier wrote:
>     Yaron> A better solution that IBTA needs to look at is creating a
>     Yaron> well known Loopback LID value that apps use when they want
>     Yaron> to talk locally (like IP 127...)
>
>If/when IBTA specifies this and available hardware implements this,
>then this will be a great solution.

As noted in my other response, the specs do not require modification to 
provide loopback service.

>In the meantime, I don't see a problem with having a mechanism to provide 
>an initial value for PortInfo:LID _before_ the SM discovers the node.  The 
>SM must be able to deal with arbitrary values of this field, since it 
>can't make any assumptions about the state of the subnet.  I don't think 
>the spec forbids having a mechanism to specify the initial value of 
>PortInfo:LID.

The SM is the only entity that is supposed to assign LID as well as the 
subnet prefix.  The SM should not trust any CA / switch configuration if it 
has not configured it thus should wipe it out and replace it with what it 
deems best.  As for the subnet merge problem, until the M_Key is sorted 
out, reassignment isn't an issue per se.

Mike

>I agree that the spec places the SM under no obligation to preserve the 
>LIDs it finds.  However, if someone wants to run an application that 
>requires loopback connections to be preserve, I see no problem with 
>requiring an SM that provides an administrative mechanism for static LID 
>assignment.
>
>The advantage of this scheme is that it requires no modifications to 
>either the IB spec or existing IB hardware.
>
>Thanks,
>   Roland
>_______________________________________________
>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/20040929/a1900b6c/attachment.html>