Changing PathRecord Settings

Applications that use PathRecords (PathSelection) to select end-to-end addresses may ignore any resultant changes and continue to use the previous settings until the application is restarted or it re-fetches its PathRecords. This can change what paths applications use (only applicable when LMC != 0) and cause application performance changes or impacts.

Activating or Deactivating Pre-Defined, Pre-Enabled vFabrics

This is intended to be permitted on a live fabric; however, applications attempting to use a deactivated vFabric will fail after the vFabric is deactivated. In general, such applications should be stopped prior to deactivating the given vFabric. Activation of a pre-defined pre-enabled vFabric is typically safe.

Changing Device Groups or Applications Associated with an Active vFabric

Applications or nodes whose assignments have changed may fail or continue executing with the old PathRecords and therefore not fully obey the change.

Changing an Active vFabric's Bandwidth, Timeouts, Priority, or Preemption/Traffic Flow Optimization Rank

This will change arbitration and scheduling within the fabric. Application operation should not be impacted; however, the performance and scheduling of fabric bandwidth will change to the new settings in a timely manner. Applications that use PathRecords to compute end-to-end timeouts may ignore any resultant changes in their timeouts and continue to use the previous timeouts until the application is restarted or refetches its PathRecords. Typically, changes to timeouts are small and have limited impact, but under extreme congestion situations, this could cause unexpected application performance impacts.

Changing Fabric Manager Virtual Lane (VL) Buffer Allocation Parameters

These parameters tune VL buffering and therefore affect application performance:

Changing Fabric Manager VL Buffer Allocation Parameters

These parameters tune VL buffering and therefore affect application performance.

Changing Parameters That are Activated Only When a Port Is Bounced

These parameters tune preemption/traffic flow optimization and therefore affect application performance

Changing CongestionControl:

Changing Routing Algorithm:

These can result in rerouting of the fabric and may briefly disrupt traffic. If incorrect (or better than previous) choices are made, fabric and application performance can be greatly affected (for better or worse).

Using ForceAttributeRewrite

This can undo previous adaptive routing decisions in switches and result in a short-term change to application performance.

Changing Fabric Manager Security Parameters

Accurate changes typically do not affect existing applications. However, security fixes or stricter policies may disable applications or nodes that previously operated in the cluster. This may be intentional when the goal is to strengthen security.

Changing Fabric Manager Multicast

Changes to FM Multicast section of parameters may impact assignments of Multicast Local Identifiers (MLIDs) to multicast groups or QoS parameters (Mtu, Rate) or Security parameters (PKey) associated with a given multicast group. Typically on FM restart, end nodes must rejoin multicast groups, and if these parameters change there can be minor disruptions of multicast traffic via lost packets. Most multicast applications will ride through these short-term disruptions without error.

Changing Fabric Timeouts

On uncongested fabrics, minor changes often do not affect applications. Significant decreases in values may cause congestion mitigation mechanisms in switches to fire sooner, resulting in packet discards and changes to application performance. Significant increases may slow switch mitigation and allow congestion to propagate further and impact application performance.

Changing Link Policies

If all active links are currently "in policy" this will have no impact on existing applications. However, mistakes or tightening of link policies may disable nodes or links in the cluster that were running prior to the change. Such changes may be intentional and desired if the goal is to tighten link policies and impact such nodes or links.

Changing Subnet Administrator (SA) Timeouts

This change affects SA query timeouts and request handling under heavy load. Most applications see little impact, but application behavior and performance may change during extreme conditions.

Changing FM SubnetSize

This alters the memory used by the FM for selected buffering and may impact FM performance. In general, there should be no impact on existing applications beyond changes to the FM's responsiveness to Performance Manager (PM) and Performance Administrator (PA) requests.

Changing QueryValidation

Cornelis recommends not changing this, as non-compliant OpenFabrics Alliance (OFA) applications may cease to work if it changes from 0 to 1.

Changing LID

This may change the LID of the Subnet Manager (SM) and briefly disrupt application queries to the SA.

Parameters that can safely be changed on a live system without impacting applications are the following: