[openib-general] [PATCH 0/6] osm: QoS policy parser
Hal Rosenstock
halr at voltaire.com
Thu Jan 25 06:11:49 PST 2007
Hi Yevgeny,
On Wed, 2007-01-24 at 09:10, 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).
This makes the start of a good document on this. If you add this to
osm/doc, I will incorporate it into the opensm man page.
> 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.
Are these Node or Port Groups ? It looks like port groups from the
below.
> 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.
How does this relate to/interact with partition configuration ? Also,
what about preexisting QoS ?
> * 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>
Is the use clause more than commentary ? How is it "used" ?
> <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>
How are port-names used ?
> </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 -->
Is this CA rather than HCA ? (What about TCAs ?)
> <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 -->
^^
Actually, it is SL
assuming the device supports SL2VL mapping as indicate by
IsSLMappingSupported in the PortInfo:CapabilityMask.
Will the syntax handle single data VL devices which only implement SL
filtering ? Will the QoS manager support this (SL2VL without VLArb
settings) or are these required together ?
> <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 don't quite follow across-from/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>
What happens if the shape of VLArb indicated here does not match the
device ?
> </vlarb-scope>
> </vlarb-tables>
> </qos-setup>
>
> <qos-levels>
> <!-- the first one is just setting SL -->
> <qos-level>
> <sn>1</sn>
What does sn mean ? What is it used for ?
> <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>
What is class ? I saw TClass mentioned earlier. Is this TClass or
something else ?
> </qos-level>
> <!-- the whole set: SL, TClass, MTU-Limit, Rate-Limit, Path-Bits -->
If specified, do MTU limit and rate limit add extra limits to be imposed
on what is selected (and realizable) ?
Strictly speaking, couldn't packet lifetime limit also be added to this
syntax here ? I presume it was left out as being not "interesting" as
yet. Is that correct ?
Also, how are path bits used ?
> <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>
What is service ? What does 22.4719 mean ?
> <match-level>3</match-level>
What are match-levels used for ?
-- Hal
> </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