[openib-general] LID assignment policy of opensm

[Hal Rosenstock]

On Fri, 2006-03-03 at 10:01, Devesh Sharma wrote:
> why It will not OK in future, Do you have some point about that?

It depends on how many multicast LIDs a switch supports. The
architecture allows for 16K - 1 which is larger than 255. A switch can
implement any number up to that.

-- Hal

> 
> On 03 Mar 2006 08:27:49 -0500, Hal Rosenstock <halr at voltaire.com>
> wrote:
>         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 
>         >         >
>         >         >
>         >         >
>         >
>         >
>         
>