[openib-general] [PATCH 0/6] osm: QoS policy parser
Sasha Khapyorsky
sashak at voltaire.com
Wed Jan 24 09:22:21 PST 2007
Hi Yevgeny,
On 16:10 Wed 24 Jan , Yevgeny Kliteynik wrote:
> 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.
>
In the discussion following RFC (available in ML archive), we talked
about to make port groups definition separate from QoS, so it could be
sharable between different OpenSM components (like QoS and Partition
manager). Any reason why it was not done?
Sasha
> * 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>
I guess "across-from" and "across-to" include all ports on the path.
What shoud hapen in case of configuration "overlap"?
> <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
> >
>
>
> _______________________________________________
> 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