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

[Hefty, Sean]

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