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

Sasha Khapyorsky sashak at voltaire.com
Wed May 6 04:21:35 PDT 2009


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.

Sasha



More information about the general mailing list