On 01:29 Fri 03 Aug , Yevgeny Kliteynik wrote: > > OK, we can use names of QoS levels instead of sequential numbers. > Here are the details: > + in qos-level new mandatory keyword 'name' will be added: "name: > single_string"
It could be even simpler: qos-level name ... > + in qos-match-rules, the 'qos-level-sn' keyword will be replaced by > 'qos-level-name' and matching just by 'qos-level' (numbers still be perfectly usable since it is string as swell). > + qos-level with name "default"/"DEFAULT" is a must. Probably single 'qos-level' without name could become default one? > It is the default level that would be applied to any PR/MPR request that > didn't > match any existing match rule > + any match rule may explicitly refer to the default qos-level by > specifying > its name in the qos-level-name > > > >>>> 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. > >>> I'm not sure it is optimal. We could have well documented or even > >>> configurable mapping rule instead, then this will not limit devices with > >>> higher capabilities. > >> I'm open for suggestions. > > The rule like %(number of OpVLs)? Or even better - configurable mapping > > rule? > >>>> * Only PR/MPR fields that have their component mask bit set should be > >>>> compared. > >>>> * For a rule to be "matching" a PR/MPR request all the rule fields > >>>> should be > >>>> "matching" their PR/MPR fields. Such that a PR/MPR request that does > >>>> not have a component mask field set for one of the rule defined > >>>> fields can > >>>> not match that rule. > >>>> * A PR/MPR request that have a component mask bit set for one of the > >>>> fields > >>>> that is not defined by the rule can match the rule. > >>> Aren't last two too restrictive? SA can just to filter-out paths in > >>> response to match rest of the rule. No? > >> Not sure I'm following. > >> The last bullet is not restrictive at all > > Right, but mostly I'm about previous bullet - where client _must_ set > > component mask to match all fields. > > Look at this this way: when you define a match rule, you specify there > only the parameters that the matching PR/MPR requests *must* comply with. > e.g., if the matching rule has service ID, it means that PR/MPR requests > that match this rule *must* have the matching service id. > Same goes for all the other PR/MPR parameters. > > You can define a 'lighter' matching rule that will match more PR/MPR > requests by checking a reduced set of key parameters. Right, and I thought about reducing number of rules. :) Sasha _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general