[ofa-general] QoS RFC

[Yevgeny Kliteynik]

Sasha Khapyorsky wrote:
> 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?

Nope. Anyway, I've implemented the "port-guid: 0x01 # bla bla" comment.

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

For now let's stay with the separate 'node-type' and 'port-guid' definitions.
I did, however, add some improvements to the file syntax - I added support
for num ranges wherever it makes sense. Example:
     port-guid: 0x10001-0x100FF,0x20000

I also added support for list of strings wherever it is needed. Examples:
     node-type: ROUTER,SELF
     destination: partition1,partition2

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

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"
  + in qos-match-rules, the 'qos-level-sn' keyword will be replaced by 'qos-level-name'
  + qos-level with name "default"/"DEFAULT" is a must.
    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.

-- Yevgeny

> Sasha
>