> Eitan wrote: > 2.2. The SM analyzes the provided policy to see if it is > realizable and performs > the necessary fabric setup. The SM may continuously monitor > the policy and adapt > to changes in it. Part of this policy defines the default > QoS-Level of each > partition. The SA is being enhanced to match the requested > Source, Destination, > TClass, Service-ID (and optionally SL and priority) against > the policy. So > clients (ULPs, programs) can obtain a policy enforced QoS. > The SM is also > enhanced to support setting up partitions with appropriate > IPoIB broadcast > group. This broadcast group carries its QoS attributes: > TClass, SL, MTU and > RATE.
While using the Service ID is an interesting idea, the problem is the Service ID values are not well defined by IBTA. Rather each endpoint is permitted to define its own, potentially transient set of Service ID values. The Service ID values are discovered via Service Records in the SA or Device Management queries which get their data from the IOU. Hence while a few service ID values are well defined (such as those for SDP), many are not (such as those for MPI, uDAPL, SRP, etc) and may vary between both hardware and software suppliers. Many are likely to be duplicated between different vendors target devices (for example a uDAPL target application may duplicate values used by an SRP target) and this would not be a problem provided both applications were never run on the same IB Node target device. Some might even change on each reboot (IBTA spec implies this could be a 64 bit pointer or context in the target), although I'm not aware of any which do. I believe it is for the above reasons that IBTA chose not to make ServiceID part of the PathRecord and MultiPathRecord queries. As Roland suggest, before implementing a non-standard approach, IBTA should be engaged to define an appropriate extension to the standard. Such extensions would need to be carefully defined to avoid breaking existing applications and fabrics. Todd Rimmer _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
