Sean Hefty wrote:
Or Gerlitz wrote:
I think the correct way here, is a SID --> QoS mapping. This allows
you to manage and configure QoS in --one-- place, namely the SM/SA and
zero effort host side deployment.
SID doesn't work for iWarp. If an IPv6 address is used, then we have
the information necessary (traffic class and flow label) to support QoS.
If an IPv4 address is used, we mimic sockets.
Sean,
As of the --importance-- && --relevancy-- I quoted Eitan's response
below, I gave it some thought and I agree with him, namely:
To mimic sockets, rdma_set_service_type() is perfectly correct and
usable by socket offloaders such as SDP and RDS, so they can translate
an IP_TOS setsockopt() call to rdma_set_service_type(). This plugs to
the case where the application wants to request per connection QoS class.
The case where the administrator wants to set the QoS attributes without
any application change must be supported and would be easily (as you
wrote) be supported if you would add the SID used by this rdma cm ID
into the path query. This would handle 100% of the rdma cm based ULPs
when IB is used as the rdma transport.
I don't think that since SID does not work for iwarp its in correct by
design to use SID for IB QoS when using the rdma cm. The rdma cm design
should work for both IB and iWARP, but it does not say that if something
is working only for IB you disallow it in the rdma cm. Using IB SID -->
QoS derivation is way more important then having design which is 100%
transport neutral.
Or.
Eitan Zahavi wrote:
Hi Or, Sean,
SID and QoSClass have a different purpose:
* SID enables the administrator to set the QoS attributes without any
application change.
(e.g. a simple rule like all SSH should have lowest priority)
* QoS Class: enables the application to request QoS class on a
per-socket manner.
It requires the application to know what it is doing and the
administrator to trust it.
It is not by chance that the two options are there in the spec.
Different communities/installations have different requirements
regarding "who controls" the policy.
For OFA development I think that providing SID should be done by default
CM based traffic:
The SID is a mandatory for making a connection and thus I do not see any
reason not to provide it in the PathRecord query.
Supporting QoS-Class is a compatibility feature supporting application
that set the TOS socket option to obtain TOS aware service over IB.
_______________________________________________
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
