[ofa-general] [PATCH 3/4] rdma/cm: add ability to specify typeof service

[Or Gerlitz]

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.