Application Service -> Service ID (or range)
Service ID -> desired QoS
QoS, SGID, DGID, PKey -> SGID, DGID, TClass, FlowLabel, PKey
SGID, DGID, TC, FL, PKey -> SLID, DLID, SL (set if crossing subnets)
SLID, DLID, SL -> MTU, Rate, VL, PacketLifeTime
What's the reasoning to use TClass and Flowlabel here? is it that you
want to come up with a scheme which is valid also for traffic crossing
IB subnets?
Yes - If you look at the data packet formats, the traffic class and flow
label are the only fields that get carried between IB subnets. They
should be sufficient to specify a desired QoS.
In a similar fashion, the LRH carries the SLID, DLID, and SL, which
should be sufficient to specify local subnet QoS.
you suggest two mappings:
A) from SID to "desired QoS"
B) from "desired QoS" (and more params) to TClass and FlowLabel
First, my understanding is that "QoS" is an abstract term here, that is
does not translate to concrete IB term, correct? now, what entity per
your design would translate from SID to QoS, is it something done
internally in the host stack similar to what the net stack does with the
IP_TOS and SOL_PRIORITY socket options?
Yes I view QoS as an abstract term, meaning we have a lot of flexibility
in how it's defined. I've chosen to define it wrt the hierarchy above.
Personally, I would drop the SID to QoS mapping, but if it is needed,
keep the mapping done on the SA side.
- Sean
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
