[openib-general] LID assignment policy of opensm

[Hal Rosenstock]

On Fri, 2006-03-03 at 07:55, Devesh Sharma wrote:
> Hi Hal,
> Thanks for replying.
> 
> On 03 Mar 2006 06:29:50 -0500, Hal Rosenstock <halr at voltaire.com>
> wrote:
>         Hi Devesh,
>         
>         On Thu, 2006-03-02 at 23:31, Devesh Sharma wrote:
>         > On 02 Mar 2006 08:35:04 -0500, Hal Rosenstock
>         <halr at voltaire.com>
>         > wrote:
>         >         Hi Devesh, 
>         >
>         >         On Thu, 2006-03-02 at 08:03, Devesh Sharma wrote:
>         >         > Hi All,
>         >         > I have another query regarding Opensm,
>         >         > What is MLID assignment policy?
>         >         > Is there any porvision that MLID assigned by
>         Opensm may 
>         >         always remain
>         >         > in 0xC001 0xC0FF range, In case by underliying
>         hardware only
>         >         255
>         >         > seprate multicast groups are supported at a time?
>         >
>         >         OpenSM does not overlay multiple groups (MGIDs) with
>         the same 
>         >         characteristics on the same MLID. It uses unique
>         MLIDs per
>         >         group.
>         >
>         > This is fine, each group will have unique MLID though  they
>         have same
>         > characteristics, I am trying to know is, 
>         > as in unicast LID assignment there is a file maintained by
>         SM, so for
>         > MLID is there any such mapping file
>         
>         No.
>         
>         > or this is maintained in some internal structure,
>         
>         The MLIDs in use are maintained in an internal structure. 
>         
>         >  or every create request with new MGID will be given One
>         higher MLID
>         > from MLID assigned to previous create request and as the
>         > switchInfo::MulticastFDBCap is reached, create request will
>         fail?
>         
>         Sort of. MLIDs are also returned when the group is reclaimed
>         some time
>         after it is deleted (last full member leaves). That leaves
>         holes in the
>         table so it is not a simple increment. Requests fail when a
>         new group 
>         creation would cause there to be MLIDs in use greater than the
>         lowest
>         SwitchInfo:MulticastFDBCap in the subnet.
>         
>         I'm not sure what your concern is here.
> 
> Here I am finding the possibility of whether 16 bit MLID can be mapped
> on a 8 bit number, which is my requirement.

That depends on the size of the MFTs in the switches (and may be OK
today but not some time in the future).

-- Hal

> Well thanks again for replying.
> 
> Devesh
> 
>         -- Hal
>         
>         >         MLIDs start at 0xC000 and are constrained by the
>         least capable 
>         >         switch
>         >         (in terms of SwitchInfo::MulticastFDBCap).
>         >
>         >         Are you just asking or are you having some issue in
>         this area
>         >         ?
>         >
>         > I am just asking about this. 
>         >
>         >         -- Hal
>         >
>         >
>         >
>         
>