On Fri, 2007-02-16 at 13:07, Roland Dreier wrote: > > For starters, I think that rate, MTU, and SL (and maybe PKey too) need > > to be the same. There may be others too if I stare at the spec for a > > while... > > Can you expand on why? For example I definitely can send to the same > MLID with different SLs.
Sure but I think this complicates the SL2VL tables in the subnet to accomodate this. I think a similar thing is true for PKeys. So to me this is an SM complexity issue when mapping multiple MGRPs to same MLID. > Of course MTU and rate need to match up but > I don't see that as a real restriction -- the SM needs to allows for > least-common-denominator values anyway, since the least-capable node > on the fabric might join an existing group. In theory, the least capable node could join any group but is this reality in operation ? Different groups could have different LCDs so this would make things less granular (one rather than multiple LCDs). This seems less constraining to me. > I don't see why one MCG with an MTU of 2048 and one MCG with an MTU of > 1024 can't share the same MLID, as long as the underlying fabric is > capable of supporting an MTU of 2048. >From a pure MTU standpoint, the (only) downside of this is that the group with MTU 1024 could send larger packets. > Actually, I wonder what the > spec says about what switches should do if they're asked to forward > packets with too-big MTUs? Maybe it all works out anyway. They get dropped on the output port as packet length > NeighborMTU. That's part of what PortXmitDiscards counts. Bottom line: I'm not sure anything precludes what you are saying (I do need to look at the spec more in terms of this), but I do think there are different levels of complexity in SM implementation depending on how much flexibility in mapping multiple MGRPs to the same MLID is "desired". -- Hal > - R. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general