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

Reply via email to