Hi Al, On Wed, Oct 29, 2008 at 12:29 PM, Al Chu <[EMAIL PROTECTED]> wrote: > Hey Hal, Yevgeny, > > On Wed, 2008-10-29 at 17:19 +0200, Yevgeny Kliteynik 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), >> so we can have different num. of VLs on switch-2-switch links >> and CA-2-switch links. >> Not sure how much value does this ability add, but perhaps we need >> to implement this configuration instead of removing the parameters... > > Implementing it would be fine instead of removing its parameters. But I > think documenting its behavior/existence and opensm not performing the > behavior is worse. If we're not going to implement it soon (I don't > mind putting it on my todo for later), perhaps we should at minimum > comment it out of the documentation/code for the time being? > > Would the QoS max_vls override the max_op_vls? Thinking about it a bit, > wouldn't a max_op_vls_ca, max_op_vls_swe, etc. parameters make more > sense than the current ones?
max_op_vls was added as an option in pre QoS days to trim things to something lower than the min of the VLCaps of the two ends of the link for adding buffering. If your direction is taken, in addition to ca and swe, there would be enhsp0 and rtr options for this too. Ultimately, it might even be more granular but that would be cumbersome to configure. Also, I would think max_op_vls of whatever flavor needs to be in concert with the QoS configuration. I'm not sure what would happen if you set it lower than what the QoS configuration "expected". Guess those other VLs (above this configured max) would not be supported and any SLs which tried to use them would get dropped. -- Hal > Al > >> -- 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 >> >>> general@lists.openfabrics.org >> >>> http:// lists.openfabrics.org/cgi-bin/mailman/listinfo/general >> >>> >> >>> To unsubscribe, please visit >> >>> http:// openib.org/mailman/listinfo/openib-general >> >> _______________________________________________ >> >> general mailing list >> >> general@lists.openfabrics.org >> >> http:// lists.openfabrics.org/cgi-bin/mailman/listinfo/general >> >> >> >> To unsubscribe, please visit >> >> http:// openib.org/mailman/listinfo/openib-general >> >> >> > >> >> > -- > Albert Chu > [EMAIL PROTECTED] > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
