[ofa-general] [opensm] remove qos_max_vls config??

[Hal Rosenstock]

On Wed, Oct 29, 2008 at 11:19 AM, Yevgeny Kliteynik
<kliteyn at dev.mellanox.co.il> 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),

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
>>>> 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
>>>
>>
>
>