An InfiniBand Service Level Does Not Identify a Dedicated Physical Lane

Separate the marking, the output VL and arbitration

When concurrent workloads use the same physical link, their class names do not tell the buyer how the link serves them. RFC 4392's April 2006 architecture overview describes VLs as virtual links within a physical link, with separate flow control. A virtual lane is therefore a logical resource within that shared connection.

NVIDIA's historical MLNX_OFED 23.10-2.1.3.1 LTS manual separates three roles. The packet's SL field carries a class marking. A switch's programmable mapping selects the output VL using the input port, output port and SL. Arbitration determines which VL is served for transmission. The numeric identifiers are not, by themselves, a priority ordering.

This article uses that historical manual only for the conceptual mapping and arbitration relationship. Current equipment support and the behavior of a supplied configuration require their own applicable evidence. The buyer's task is to connect the advertised class to that behavior, rather than assume a larger label means better service.

References: [R1][N1]

Follow three fictional labels to two output destinations

Consider a wholly fictional switch with input I and output X. Stipulate this mapping for packets arriving at I and leaving through X: SL 2 selects VL 0, SL 6 selects VL 1, and SL 9 selects VL 0. Every identifier and mapping in this example is invented for explanation; none is a setting to adopt.

There are three SL labels but only two selected VL destinations at X. Traffic marked SL 2 and traffic marked SL 9 join the same output VL. Giving those workloads different names has not given each a separate participant in arbitration between VLs. SL 6 reaches the other VL, but the example has specified no arbitration policy that would make it higher priority.

Now stipulate a second output Y for the same input I: SL 2 selects VL 1, SL 6 selects VL 1, and SL 9 selects VL 0. At Y, SL 2 and SL 6 share a destination instead. This is an alternative output relationship, not a claim that the same packet traverses both outputs.

A statement that SL 2 and SL 6 use different VLs is true for the stipulated X mapping and false for Y. That counterexample is why a buyer cannot extend a mapping shown for one input/output combination to every switch output along a path. The class labels alone leave the relevant resource relationships unresolved.

References: [N1]

Keep the scheduling resource separate from the promised outcome

The fictional X mapping tells us where the three marked traffic classes go. It gives no transmission share. Counting two selected VLs does not establish a half-and-half split; counting three labels does not establish thirds. Neither arithmetic has an arbitration policy or a competing-traffic condition behind it.

Even if two classes reach different VLs at every relevant output, that finding would establish a narrower resource distinction than a bandwidth or latency commitment. To assess a promised outcome, the buyer still needs to know how the supplied system serves those lanes when the stated workloads compete. A configured policy and a demonstrated application result are also different kinds of evidence.

The mapping creates no additional cable, connector or physical path. It is not evidence of security isolation either. A proposal using dedicated must therefore say which resource or outcome is dedicated. Otherwise, a buyer may price a label as though it supplied independent infrastructure or a performance commitment that has never been established.

References: [N1][R1]

Read NCCL trafficClass in its version and transport

NVIDIA's NCCL 2.32.3 communicator guide describes assigning a traffic class to a communicator; its network operations use that class. The meaning is specific to the network plugin. In the documented InfiniBand case, trafficClass corresponds to an SL. For RoCE, it is interpreted as an IP Type of Service (ToS). Available classes and their relative behavior depend on the system configuration.

Consequently, copying the same number between an InfiniBand proposal and a RoCE proposal does not establish equivalent policy. The buyer must connect each value to the actual transport and supplied behavior. The same applies when comparing two systems with different class definitions.

The guide's example of differentiated service belongs to its stated configuration. It supplies no universal ranking for arbitrary numeric labels and no reason to assume that a communicator class reserves its own physical connection.

References: [N2]

Compare the promise under the stated competing traffic

Suppose a fictional offer promises that training and checkpoint traffic receive independent bandwidth because they have different SLs. The useful buying question is what independent means. If the supporting explanation stops at the two markings, it has not answered whether the workloads share a VL at a relevant output, how their VLs are served, or what result is promised while both are active.

Ask the supplier or appointed network owner to explain the class-to-resource relationship for the paths covered by that offer, using the actual equipment and software context. Keep the arbitration behavior and the competing traffic explicit. A diagram showing separate destinations at one output supports only that local distinction; it cannot establish the behavior throughout the offered fabric.

If the purchase depends on a bandwidth share or latency outcome, identify the conditions and evidence supporting that particular promise. A result from one workload running alone cannot establish its behavior with the proposed competitor active. The relevant comparison concerns the same required outcome under the stated concurrency, with the producing configuration identified.

This makes the commercial distinction usable: a class label describes requested treatment, a supported fabric policy describes how resources serve traffic, and workload evidence supports a claim about the resulting behavior. The existing NCCL metric and acceptance guides help interpret submitted results; neither a metric name nor a class number supplies the missing QoS promise.

Scope physical cabling from the approved connection package

The linked InfiniBand/RoCE connection-package article addresses switches, interfaces and physical assemblies. The RoCE congestion article addresses pauses, packet marking and receiver feedback. Those are adjacent questions; neither substitutes for understanding the SL-to-VL relationship.

For separately approved physical work, Leviathan's structured cabling service can cover agreed installation, routing, dressing, labeling, checks and connection records using customer-furnished or separately sourced materials. Fabric configuration and QoS validation remain with the appointed network specialists.

Use the related service and project inquiry to discuss that physical package. Share the site, approved endpoint and assembly schedule, routes, work window and required handoff records. A traffic-class label alone does not define a change to the cabling scope.