[openib-general] [PATCH 0/6] osm: QoS policy parser
Yevgeny Kliteynik
kliteyn at dev.mellanox.co.il
Wed Jan 24 06:09:09 PST 2007
Hi Hal, Sasha.
Here's a description of the QoS policy file, and an
example of such file (with more comments inside).
QoS Policy file
---------------
The QoS policy file is divided into 4 sub sections:
* Node Group: a set of HCAs, Routers or Switches that share the same settings.
A node groups might be a partition defined by the partition manager policy in
terms of GUIDs. Future implementations might provide support for NodeDescription
based definition of node groups.
* Fabric Setup:
Defines how the SL2VL and VLArb tables should be setup. This policy definition
assumes the computation of target behavior should be performed outside of
OpenSM.
* QoS-Levels Definition:
This section defines the possible sets of parameters for QoS that a client might
be mapped to. Each set holds: SL and optionally: Max MTU, Max Rate, Path Bits
(in case LMC > 0 is used for QoS) and TClass.
* Matching Rules:
A list of rules that match an incoming PathRecord request to a QoS-Level. The
rules are processed in order such as the first match is applied. Each rule is
built out of set of match expressions which should all match for the rule to
apply. The matching expressions are defined for the following fields
- SRC and DST to lists of node groups
- Service-ID to a list of Service-ID or Service-ID ranges
- TClass to a list of TClass values or ranges
QoS policy file example
-----------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<qos-policy>
<!-- Port Groups define sets of ports to be used later in the settings -->
<port-groups>
<!-- using port GUIDs -->
<port-group>
<name>Storage</name>
<use>our SRP storage targets</use>
<port-guid>0x1000000000000001</port-guid>
<port-guid>0x1000000000000002</port-guid>
</port-group>
<!-- using names obtained by concatenation of first 2 words of NodeDescription
and port number -->
<port-group>
<name>Virtual Servers</name>
<use>node desc and IB port #</use>
<port-name>vs1/HCA-1/P1</port-name>
<port-name>vs3/HCA-1/P1</port-name>
<port-name>vs3/HCA-2/P1</port-name>
</port-group>
<!-- using partitions defined in the partition policy -->
<port-group>
<name>Partition 1</name>
<use>default settings</use>
<partition>Part1</partition>
</port-group>
<!-- using node types HCA|ROUTER|SWITCH -->
<port-group>
<name>Routers</name>
<use>all routers</use>
<node-type>ROUTER</node-type>
</port-group>
</port-groups>
<qos-setup>
<!-- define all types of SL2VL tables always have 16 VL entries -->
<sl2vl-tables>
<!-- scope defines the exact devices and in/out ports the tables apply to
if the same port is matching several rules the last one applies -->
<sl2vl-scope>
<group>Part1</group>
<from>*</from>
<to>*</to>
<sl2vl-table>0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7</sl2vl-table>
</sl2vl-scope>
<!-- also the link across port 1 is probably supporting only 2 VLs -->
<sl2vl-scope>
<across>Storage</across>
<!-- "across-from" means the port just connected to the given group -->
<across-from>Storage2</across-from>
<!-- "across-to" means the port just connected *to* the given group -->
<across-to>Storage3</across-to>
<from>*</from>
<to>1</to>
<sl2vl-table>0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0</sl2vl-table>
</sl2vl-scope>
</sl2vl-tables>
<!-- define all types of VLArb tables. The length of the tables should
match the physically supported tables by their target ports -->
<vlarb-tables>
<!-- scope defines the exact ports the VLArb tables apply to -->
<vlarb-scope>
<group>Storage</group>
<!-- VLArb table holds VL and weight pairs -->
<vlarb-high>0:255,1:127,2:63,3:31,4:15,5:7,6:3,7:1</vlarb-high>
<vlarb-low>8:255,9:127,10:63,11:31,12:15,13:7,14:3</vlarb-low>
<vl-high-limit>10</vl-high-limit>
</vlarb-scope>
</vlarb-tables>
</qos-setup>
<qos-levels>
<!-- the first one is just setting SL -->
<qos-level>
<sn>1</sn>
<use>for the lowest priority comm</use>
<sl>16</sl>
</qos-level>
<!-- the second sets SL and TClass -->
<qos-level>
<sn>2</sn>
<use>low latency best bandwidth</use>
<sl>0</sl>
<class>7</class>
</qos-level>
<!-- the whole set: SL, TClass, MTU-Limit, Rate-Limit, Path-Bits -->
<qos-level>
<sn>3</sn>
<use>just an example</use>
<sl>0</sl>
<class>32</class>
<mtu-limit>1</mtu-limit>
<rate-limit>1</rate-limit>
</qos-level>
</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>
<qos-level-sn>1</qos-level-sn> <!-- defined in <sn> of <qos-level> -->
<use>low latency by class 7-9 or 11</use> <!-- just a description -->
<class>7-9,11</class> <!-- -->
<match-level>1</match-level> <!-- ID of this match rule -->
</qos-match-rule>
<!-- show matching by destination group AND service-ids -->
<qos-match-rule>
<qos-level-sn>2</qos-level-sn>
<use>Storage targets connection></use>
<destination>Storage</destination>
<service>22,4719</service>
<match-level>3</match-level>
</qos-match-rule>
</qos-match-rules>
</qos-policy>
-- Yevgeny
Yevgeny Kliteynik wrote:
> Hi Sasha,
>
> Sasha Khapyorsky wrote:
>> On 10:46 Sun 21 Jan , Yevgeny Kliteynik wrote:
>>> Hi Sasha.
>>>
>>> Sasha Khapyorsky wrote:
>>>> Hi Yevgeny,
>>>>
>>>> On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote:
>>>>> Hi Hal
>>>>>
>>>>> The following series of six patches implements QoS policy file parser:
>>>>>
>>>>> 1. QoS parser Lex file
>>>>> 2. QoS parser Lex-generated c file
>>>>> 3. QoS parser grammar (Yacc) file
>>>>> 4. QoS parser Yacc-generated grammar c and h file
>>>>> 5. QoS parser header file that defines parse tree data structures
>>>>> 6. Changes in makefiles and configure.in file for compiling QoS parser files
>>>> Is there any description of proposed format and functionality?
>>> The parser is based on QoS RFC sent by Eitan in May 2006, with a few
>>> minor modifications. You can find the RFC here:
>>> http://openib.org/pipermail/openib-general/2006-May/022336.html
>> This was RFC and couple of issues were discussed then. Now you are about
>> implementation phase and exact format description would be desired. For
>> example what "few minor modifications" are?
>
> I'll prepare an example file with explanations.
>
> -- Yevgeny
>
>>>> Also what about using human readable formats?
>>> To me the xml-like format in the RFC looks pretty readable.
>>> It has very limited number of keywords (tags), so it's easy
>>> to follow and/or to modify.
>> It is your opinion, not everybody will agree with it (AFAIR this was
>> discussed too during RFC).
>>
>> I would not be care, but I don't know any example of really successful
>> XML using for configuration purposes (especially where advanced graphical
>> config editors/viewers were not used). Do you know?
>>
>> Sasha
>>
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
More information about the general
mailing list