[openib-general] LID assignment policy of opensm

[Devesh Sharma]

why It will not OK in future, Do you have some point about that?

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
> >         >
> >         >
> >         >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060303/5b0017b8/attachment.html>