[ofa-general] QoS RFC

[Sasha Khapyorsky]

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