[ofa-general] [PATCH] osm_port.c: do not force max_op_vls = 0 to 1

[Hal Rosenstock]

On Wed, May 6, 2009 at 7:21 AM, Sasha Khapyorsky <sashak at voltaire.com> wrote:
> On 09:59 Tue 05 May     , Hal Rosenstock wrote:
>> >>
>> >> Should that only be done when max_op_vls is 0 ?
>> >>
>> >> Something like:
>> >> ?? ?? ?? ?? ?? ??if (op_vls > p_subn->opt.max_op_vls)
>> >> ?? ?? ?? ?? ?? ?? ?? ?? op_vls = p_subn->opt.max_op_vls;
>> >> ?? ?? ?? ?? ?? ??else if (op_vls == 0) {
>> >> ?? ?? ?? ?? ?? ?? ?? ??OSM_LOG(p_log, OSM_LOG_DEBUG, "ERR 4102: "
>> >> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??"Invalid OP_VLS = 0. Forcing correction to 1 (VL0)\n");
>> >> ?? ?? ?? ?? ?? ?? ?? ??op_vls = 1;
>> >> ?? ?? ?? ?? ?? }
>> >
>> > why do you suggest a special case for op_vls=0 (and not for other portinfo fields)?
>>
>> > is there a firmware bug that reports op_vls=0?
>>
>> There were (still are ?) implementations which returned op_vls 0 which
>> is why the words "valid on Set()" were added to the IBA spec and why I
>> don't feel safe removing the code as originally proposed but think my
>> alternative is safe and accomplishes the stated goal. Is there a
>> problem with my alternative proposal ?
>
> Assuming that all this was done as workaround for buggy OperVLs report
> its relevance shouldn't be a function of max_op_vls configuration value.
>
> I see two independent issues here: (1) removing (or keeping) zero
> OperVLs report workaround and (2) support and proper handling
> max_op_vls = 0 configuration value.

Agreed and IMO (as I stated in previous emails) the workaround should
be kept as I don't think there is a way of knowing for sure that those
non compliant implementations are not in the field anymore. If the
push is to remove this, then maybe another option for this workaround
should be added with the default being to have the workaround off.

-- Hal

>
> Sasha
>