***SPAM*** Re: [ofa-general] [opensm] remove qos_max_vls config??

[Hal Rosenstock]

Hi Al,

On Wed, Oct 29, 2008 at 12:29 PM, Al Chu <chu11 at llnl.gov> 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
>> > <kliteyn at dev.mellanox.co.il> 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 at 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 at 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
> chu11 at llnl.gov
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
>
>