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 _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general