why It will not OK in future, Do you have some point about that?<br><br><div><span class="gmail_quote">On 03 Mar 2006 08:27:49 -0500, <b class="gmail_sendername">Hal Rosenstock</b> <<a href="mailto:halr@voltaire.com">halr@voltaire.com

</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Fri, 2006-03-03 at 07:55, Devesh Sharma wrote: > Hi Hal, > Thanks for replying.

<br>><br>> On 03 Mar 2006 06:29:50 -0500, Hal Rosenstock <<a href="mailto:halr@voltaire.com">halr@voltaire.com</a>><br>> wrote:<br>>         Hi Devesh,<br>><br>>         On Thu, 2006-03-02 at 23:31, Devesh Sharma wrote:

<br>>         > On 02 Mar 2006 08:35:04 -0500, Hal Rosenstock<br>>         <<a href="mailto:halr@voltaire.com">halr@voltaire.com</a>><br>>         > wrote:<br>>         >         Hi Devesh,<br>>         >

<br>>        

>         On Thu, 2006-03-02

at 08:03, Devesh Sharma wrote:<br>>         >         > Hi All,<br>>        

>         > I have

another query regarding Opensm,<br>>        

>         > What is MLID

assignment policy?<br>>        

>         > Is there any

porvision that MLID assigned by<br>>         Opensm may<br>>         >         always remain<br>>        

>         > in 0xC001

0xC0FF range, In case by underliying<br>>         hardware only<br>>         >         255<br>>        

>         > seprate

multicast groups are supported at a time?<br>>         ><br>>        

>         OpenSM does not

overlay multiple groups (MGIDs) with<br>>         the same<br>>        

>         characteristics on

the same MLID. It uses unique<br>>         MLIDs per<br>>         >         group.<br>>         ><br>>         > This is fine, each group will have unique MLID though  they<br>>         have same<br>

>         > characteristics, I am trying to know is,<br>>         > as in unicast LID assignment there is a file maintained by<br>>         SM, so for<br>>         > MLID is there any such mapping file

<br>><br>>         No.<br>><br>>         > or this is maintained in some internal structure,<br>><br>>         The MLIDs in use are maintained in an internal structure.<br>><br>>         >  or every create request with new MGID will be given One

<br>>         higher MLID<br>>         > from MLID assigned to previous create request and as the<br>>         > switchInfo::MulticastFDBCap is reached, create request will<br>>         fail?<br>><br>

>         Sort of. MLIDs are also returned when the group is reclaimed<br>>         some time<br>>         after it is deleted (last full member leaves). That leaves<br>>         holes in the<br>>         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).

<br><br>-- Hal<br><br>> Well thanks again for replying.<br>><br>> Devesh<br>><br>>         -- Hal<br>><br>>        

>         MLIDs start at

0xC000 and are constrained by the<br>>         least capable<br>>         >         switch<br>>        

>         (in terms of

SwitchInfo::MulticastFDBCap).<br>>         ><br>>        

>         Are you just

asking or are you having some issue in<br>>         this area<br>>         >         ?<br>>         ><br>>         > I am just asking about this.<br>>         ><br>>         >         -- Hal

<br>>         ><br>>         ><br>>         ><br>><br>><br><br></blockquote></div><br>