[openib-general] QoS RFC - Resend using a friendly mailer

[Eitan Zahavi]

Hi Sasha,

Please see my comments below

> >
> > 9. OpenSM features
> > -------------------
> > The QoS related functionality to be provided by OpenSM can be split
into two
> > main parts:
> >
> > 3.1. Fabric Setup
> > During fabric initialization the SM should parse the policy and
apply its
> > settings to the discovered fabric elements. The following actions
should be
> > performed:
> > * Parsing of policy
> > * Node Group identification. Warning should be provided for each
node not
> >   specified but found.
> > * SL2VL settings validation should be checked:
> >   + A warning will be provided if there are no matching targets for
the SL2VL
> >     setting statement.
> >   + An error message will be printed to the log file if an invalid
setting is
> >     found. A setting is invalid if it refers to:
> >     - Non existing port numbers of the target devices
> >     - Unsupported VLs for the target device. In the later case the
map to non
> >       existing VLs should be replaced to VL15 i.e. packets will be
dropped.
> 
> Not sure that unsupported VLs mapping to VL15 is best option. Actually
> if SL2VL will be specified per port group this may mean that at least
in
> "generic" case all group members should have similar physical
> capabilities or "reliable" part of SLs will be limited by lowest VLCap
> in this group (other SLs will be just dropped somewhere).
[EZ] I prefer not hiding the mismatch. In my mind the explicit setting
should be provided for each of the groups of switches that do not share
same VLs support. 
But this is not a strong requirement in my mind. In general I would
prefer to get a clear error message when the fabric can not support the
given policy. Once such error is provided I think we could use whatever
"recovery" option you have in mind.
> 
> In current SL2VL mapping implementation we are using such rule to
replace
> unsupported VLs: (new VL) = (requested VL) % (operational data VLs)
> This may have some disadvantage too, but I think it is generally
"safer".
[EZ] It is safer since it will not cause data loss. But then the QoS
will probably be broken.
> 
> Also I guess that by "unsupported VLs" you are referring unsupported
or
> non-configured VLs.
[EZ] Yes true.
> 
> > * SL2VL setting is to be performed
> > * VL Arbitration table settings should be validated according to the
following
> >   rules:
> >   + A warning will be provided if there are no matching targets for
the setting
> >     statement
> >   + An error will be provided if the port number exceeds the target
ports
> >   + An error will be generated if the table length exceeds device
capabilities
> >   + An warning will be generated if the table quote a VL that is not
supported
> >     by the target device
> 
> Should there be replacement rule for not supported VLs?
> 
> In IBTA spec (v.1, p.190, l.14) is stated that entry with unsupported
VL
> may be skipped _OR_ "trusted" to other (supported) VL. I think if we
will
> not care about unsupported replacement there may be hole for
> "device/vendor dependent" behavior.
[EZ] OK good point. Lets have a replacement rule.
> 
> Sasha