We should discuss this at the next OFIWG. The way QoS works for IB and OPA is that there's a mapping from a sockaddr port to an assigned QoS level (implemented using service level). That mapping is controlled by the management software.
I believe sockets handles this using setsockopt() for ToS. That would map to fi_setopt(), and would just need definitions to indicate the endpoint level, option name, and value. There's a similar sort of mapping defined for the librdmacm. So, this would allow mapping ToS to the verbs, tcp, and udp providers. - Sean > The only mention I see of it is in the URI specified in the > FI_ADDR_STR example in the fi_getinfo() man page. Since my goal is > to bind different traffic classes to different transmit contexts for > a scalable endpoint, specifying TC/QOS as part of the address > doesn’t fill my need. I’d want an extra parameter to fi_tx_attr. In > my head, this an index that functions as an abstract traffic class, > but the actual policy, if any, would be provided by the lower-level > driver or a higher level management tool. So a TC of zero or one, > would have no particular meaning to the API, it is just a label to > be interpreted by something else in the stack and it will simply be > ignored by providers that don’t support it. > > > > There is always the vendor-specific route, if need be. > > > > John Byrne > > _______________________________________________ ofiwg mailing list ofiwg@lists.openfabrics.org http://lists.openfabrics.org/mailman/listinfo/ofiwg