[ofa-general] Re: QoS in RDMA CM: (was QoS RFC)

[Sean Hefty]

> In the socket API, socket options describe what protocol they are 
> intended for.  You can have options that are intended for IP or TCP and 
> other protocol layers.
> 
> We could do some rdma_setopt() interface, and define both transport 
> independent options and transport-specific options.  Then if there are 
> features of qos that are only in IB, you can make them 
> transport-specific options.  So an option struct may have a 
> transport_type field...
> 
> Although I _think_ it will be a good thing to try and map 
> transport-specific qos attributes to a univeral transport independent 
> attribute.  But I'm not an expert on qos stuff...

Based on the information I found, socket options are used to specify QoS 
/ TOS / DSCP / whatever they want to call it for IPv4, but not for IPv6. 
  For IPv6, the TC and FL fields are included with the socket address.

So... I think we're okay with IPv6, but will need an rdma_setopt() call 
to set the QoS info for IPv4 addresses.  I think we can keep the QoS 
attributes transport independent.

Note that for IB, we could avoid the rdma_setopt() call by mapping the 
resulting IB service ID to a QoS level, but I'd rather find a transport 
independent solution if possible.

> Or a more generic rdma_setopt() that can be extensible for future 
> options/attributes and not break the API...

I agree - my preference is not to break the user space API.

- Sean