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
_______________________________________________
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
