[ofiwg] Any plans to add traffic-class/qos to the API?

Hefty, Sean sean.hefty at intel.com
Mon Apr 16 17:43:01 PDT 2018

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

More information about the ofiwg mailing list