On Wed, Oct 29, 2008 at 11:19 AM, Yevgeny Kliteynik <[EMAIL PROTECTED]> wrote: > Hal Rosenstock wrote: >> >> On Wed, Oct 29, 2008 at 5:13 AM, Yevgeny Kliteynik >> <[EMAIL PROTECTED]> wrote: >>> >>> Al Chu wrote: >>>> >>>> Hey Sasha, >>>> >>>> I was working on a different bug fix on the qos config parsing, when I >>>> noticed the qos_*max_vls fields aren't used anywhere. They seem to be >>>> parsed from the config, stored, and never used. Maybe it used to be >>>> what 'max_op_vls' is now used for? >>> >>> I guess that the initial idea was to have an option to configure >>> different operational VLs on different type of nodes in the subnet. >>> The question is, does having such option make sense? >> >> Does it impact buffering ? If so, in those cases it would be worth >> configuring (assuming it gets acted on elsewhere). > > Right, it does impact buffering. > I think that OpenSM always sets the same op_vls on both sides of > the link (if there is a mismatch, SM will set the lowest value),
Right, it takes the VLCaps on the two ends of the link and set OpVLs on both sides to the lower value. > so we can have different num. of VLs on switch-2-switch links > and CA-2-switch links. Assuming switches having one VLCap and CAs another. It might be more diverse than that in terms of switches and CAs in use. > Not sure how much value does this ability add, Me neither. I'm not sure whether the main determinant is VLCap or OpVLs or some combination of the two (in terms of buffering). The only data I have as to whether this makes any difference at all is that the buffering effects are observed with long latency links. > but perhaps we need > to implement this configuration instead of removing the parameters... I agree. I think this might be useful or at least gather better data on it so I'd rather see it implemented than excised. -- Hal > -- Yevgeny > >> -- Hal >> >>> -- Yevgeny >>> >>>> If there's still a purpose for it in the future, obviously no issue on >>>> leaving in there. Patch is attached to remove it everywhere I found it. >>>> >>>> Al >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> general mailing list >>>> [email protected] >>>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general >>>> >>>> To unsubscribe, please visit >>>> http://openib.org/mailman/listinfo/openib-general >>> >>> _______________________________________________ >>> general mailing list >>> [email protected] >>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general >>> >>> To unsubscribe, please visit >>> http://openib.org/mailman/listinfo/openib-general >>> >> > > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
