[ofiwg] Pull Request: Support for traffic classes in Libfabric

[James Swaro]

A pull request has been opened for the initial support of traffic classes for libfabric. Please review as appropriate.

https://github.com/ofiwg/libfabric/pull/5148

This commit introduces the capability to select a traffic class when
creating libfabric objects with the goal to allow applications to
utilize traffic shaping mechanisms exposed to providers.

In this proposal, the fi_domain, fi_tx_attr, and fi_rx_attributes are
modified to add the new fi_traffic_class structure to the structure definition.
The fi_traffic_class structure provides a 'type' field, indicating the type of
traffic class value that is represented in the 'value' field of the structure.
Two different types of traffic class are presented with this commit; FI_TC_TYPE_LABEL,
and FI_TC_TYPE_DSCP. Libfabric defines generalized traffic classes via community
defined labels and expected behavior for those labels, which fall under the category
of FI_TC_TYPE_LABEL. Providers may also define provider specific labels utilizing the
most significant 32 bits of the value field. To provide applications with greater
control over traffic class selection, this proposal exposes the ability to specify
a specify DSCP value to be associated with libfabric objects, using the value field set
to the DSCP value, and type set to FI_TC_TYPE_DSCP.

Additionally, to simplify the traffic class selection process, this commit introduces
a heirarchal inheritance model with the fi_traffic_class structure. When an fi_domain
is created, the application can choose to select a traffic class, or allow the provider
to select a default traffic class. The traffic class associated with the domain is used
as the default for all objects created within the domain. This allows an
application to request a general traffic class for most traffic flows, while
allowing the application to finely control traffic at the granularity of the tx context
or rx context.

The original proposal to OFIWG did not include the rx context modification. However,
multi-part data transfer operations such as rendezvous messaging benefit from the differentiation of
request and response traffic shaping flows. The traffic class field in the rx attribute is
only intended to apply to these multi-part data transfer operations and does not imply any
relation with the tx attribute of a peer endpoint.

-- Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20190701/edd847f8/attachment.html>