[ofa-general] QoS RFC

[Sasha Khapyorsky]

Hi Yevgeny,

On 15:39 Thu 26 Jul     , Yevgeny Kliteynik wrote:
> >>
> >>  * Comments may appear only in a separate line
> > Why? What is wrong with:
> > 	port-name: vs1/HCA-1/P1   # my best port
> 
>  I can use this too, but then the pound sign, wherever it will
>  appear, would mean commentary start. No \# or something like this
>  to include it in some other place - I don't want to complicate the
>  syntax. Sounds OK?

Are we planning to use '#' somewhere?

Anyway this comment is minor.

> >>      end-port-groups
> > I agree that proposed syntax has better for human readability than pure
> > XML, but isn't stuff like this will be more user-friendly?
> > Storage "Free Text description" = 0x10001, 0x10002, 0x10003 ;
> > , or
> > Storage "Free Text description" { 0x10001, 0x10002, 0x10003 };
> > , or
> > Storage "Free Text description": ROUTERS, CAS ;
> 
>  GUID list is a good idea.
>  Not sure about the other stuff. A certain port group can be defined
>  both by guids and by node-types. How about this:
> 
>            port-group
>                name: routers_and_mgt_nodes
>                use: all routers and management nodes
>                node-type: ROUTER
>                port-guid: 0x10001, 0x10002, 0x10003
>            end-port-group

I think it is doable too, like: 0x10001, 0x10002, 0x10003, ROUTER
Guess it should be easy to parse GUIDs, names and special names (like
ROUTER) in one line. Not sure it must be so, just thought...

> >>      qos-levels
> >>
> >>          # the first one is just setting SL
> >>          qos-level
> >>              use: for the lowest priority communication
> >>              sl: 15
> >>              packet-life: 16
> >>          end-qos-level
> >>          # the second sets SL and QoS Class
> >>          qos-level
> >>              use: low latency best bandwidth
> >>              sl: 0
> >>          end-qos-level
> >>          # the whole set: SL, MTU-Limit, Rate-Limit, Packet Lifetime, Path 
> >>  Bits
> >>          qos-level
> >>              use: just an example
> >>              sl: 0
> >>              mtu-limit: 1
> >>              rate-limit: 1
> >>              packet-life: 12
> >>              # Path Bits can be used e.g. to provide a different routes  
> >> through the
> >>              # subnet to a particular port
> >>              path-bits: 2,4,8-32
> >>          end-qos-level
> >>
> >>      end-qos-levels
> >>
> >>
> >>      # Match rules are scanned in a first-fit manner (like firewall rules  
> >> table)
> >>      qos-match-rules
> >>
> >>          # matching by single criteria: class (list of values and ranges)
> >>          qos-match-rule
> >>              # just a description
> >>              use: low latency by class 7-9 or 11
> >>              qos-class: 7-9,11
> >>              # number of qos-level to apply to the matching PR/MPR
> >>              qos-level-sn: 1
> > Isn't it better and less error prone to match qos_level by name and not
> > by sequential number?
> 
>  qos-level can have name, and then qos-match-rule will refer to this name.
>  But matching qos-level by sequential number makes it really easy to locate
>  the referred qos-level, which is important, as every PR/MPR request would
>  go through this process, so saving some runtime in this area is important 
>  IMHO.

Sure, it is important, but I'm not about internal data representation,
internally this should be fast reference - by index or by directly by
pointer. But in the file it would be easy for user to have names (numbers
could be used as names too) instead of just serial numbering on one
side, so an user will not need to count lines.


> >>  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.

Sasha