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
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
