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 <[EMAIL PROTECTED]> > 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 > <[EMAIL PROTECTED]> > > wrote: > > Hi Devesh, > > > > On Thu, 2006-03-02 at 23:31, Devesh Sharma wrote: > > > On 02 Mar 2006 08:35:04 -0500, Hal Rosenstock > > <[EMAIL PROTECTED]> > > > 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 > > > > > > > > > > > > > > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
