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

_______________________________________________
ofiwg mailing list
[email protected]
https://lists.openfabrics.org/mailman/listinfo/ofiwg

Reply via email to