Skip to main content
This page lists the Scala RoCE NIC attributes, with their types and defaults, and shows how to set them. A simulation configuration can set every attribute listed except the read-only NumDownLinks. The tables list the attributes the components API offers for the Scala RoCE NIC, grouped by the component that holds them: the NIC itself, its network interface and buffers, its PCIe host interface, its transport layer, its queue pair manager, and its ECN handler. The page ends with the configuration rules that stop a simulation. Transport, Buffers and PFC, and Congestion control explain the behavior behind them.

How to read the tables

Default is the value an attribute carries in a NIC the platform adds to a configuration, for example with POST /api/v1/configurations/{config_id}/components. Such a NIC carries every attribute in these tables at its Default until you change it. If you supply a NIC’s typedParameters yourself instead, for example in the components of POST /api/v1/configurations, include every attribute of each sub-component you send, such as IngressBufferManager or ECNHandler: an attribute left out of it runs the model’s built-in value, which can differ from the Default shown here. Attributes at the NIC’s top level, and sub-components you leave out entirely, take their Defaults. Type is the value of the attribute’s type field in the API, which a patch must repeat. Values of type bytes, queuesize, datarate, and timeval carry a unit: sizes are in B, KB, KiB, MB, or MiB, where KB is 1,000 bytes, KiB 1,024 bytes, and MB 1,000,000 bytes; data rates are in Gbps or Mbps; times are in ps, ns, us (µs), ms, or s. Attributes of type string that hold a list, such as PoolAllocationVector, hold eight comma-separated entries, where the index is the traffic class, 0 to 7; PoolAllocationVector also has a rule for where its non-zero entries go (Buffer pools). The platform shows them in square brackets, for example [0.9, 0.1, 0, 0, 0, 0, 0, 0]. Send them the same way when you change one: as a string, with the brackets and all eight entries (Change values in a configuration).

NIC

These attributes sit at the top level of the NIC component’s typedParameters.

Network interface

The NetworkInterface component holds four sub-components: UplinkNetworkInterface, the NIC’s Ethernet port to its rack switch; TransmissionMedium, the link; and IngressBufferManager and EgressBufferManager, the receive and transmit buffers.

UplinkNetworkInterface

TransmissionMedium

IngressBufferManager

The receive buffer. Receive buffer and PFC explain how it is used.

EgressBufferManager

The transmit buffer. Egress buffer and Transmit scheduling explain how it is used.

Host interface

The HostInterface component holds the PCIe link between the NIC and its host, as two sub-components: NICSide, the NIC’s end of the link, and HostSide, the host’s end. Fetching the payload over PCIe explains how a transfer uses them, with a worked example of the rates. Each end holds a container named PCIeGen3.0. The name does not set the PCIe generation: each end’s LaneBps does, and the default 31.52 Gbps per lane is the PCIe 5.0 rate.

NIC side

On the NIC’s end of the link, each attribute’s path in the NIC’s typedParameters is:
  • RXHeaderBufferSize, TXHeaderBufferSize, RXDataBufferSize, TXDataBufferSize: HostInterface → NICSide → PCIeGen3.0 → NicDeviceLayer → NicPCIeInterface → TransactionLayer
  • LaneBps, LaneCount: HostInterface → NICSide → PCIeGen3.0 → NicDeviceLayer → NicPCIeInterface → PhysicalLayer
  • ReadRequestSize: HostInterface → NICSide → NICPCIeHandler

Host side

On the host’s end of the link:
  • RXHeaderBufferSize, TXHeaderBufferSize, RXDataBufferSize, TXDataBufferSize: HostInterface → HostSide → PCIeGen3.0 → ScalaHostPCIeDeviceLayer → HostPCIeInterface → TransactionLayer
  • LaneBps, LaneCount: HostInterface → HostSide → PCIeGen3.0 → ScalaHostPCIeDeviceLayer → HostPCIeInterface → PhysicalLayer

Transport processing layers

The TransportProcessingLayers component holds the NIC’s processing layers. Only the transport layer has attributes.

RoceTransportLayer

Acknowledgements and Retransmission timer explain how these combine.

ScalaRoceQpManager

The ScalaRoceQpManager component manages the NIC’s queue pairs.

ECNHandler

The ECNHandler component holds the rate control loop’s settings, which apply to every queue pair on the NIC. The rate control loop explains each stage.

Setting attributes through the platform

Attributes are set per configuration, through the platform API. The reference pages for the two APIs involved are Components and Configurations. Get an API token first (Authentication) and export it as SCALA_API_TOKEN.

Read the NIC’s parameters

GET /api/v1/components lists the component types the platform offers; the Scala RoCE NIC entry, ScalaRoceNic, gives its id and its versions. GET /api/v1/components/{component_id}, with the version query parameter set to the model version these pages describe, returns the NIC’s typedParameters. Each attribute in the tables above appears there as an object with its value, its type, a unit for dimensional types, and, where the model sets them, its default, description, min, max, and allowed values in enum; NumDownLinks also carries readonly. A sub-component, such as NetworkInterface or ECNHandler, is a nested object named after it. For example:

Add the NIC to a server

A Scala RoCE NIC belongs to a server component: every instance of that server carries one NIC with the same typedParameters. Placing it takes two calls:
  1. POST /api/v1/configurations/{config_id}/components, with the query parameters modelId=ScalaRoceNic, type=nic, a name for the NIC component, and version, adds the NIC to the configuration with every attribute at its Default.
  2. PATCH /api/v1/configurations/{config_id}/configurations/{component_name}, where component_name is the server component, adds the NIC to that server. The body names the NIC component, with type nic and count 1.
Set CONFIG_ID to the configuration’s ID and SERVER_NAME to the name of the server component, which must already be in the configuration; GET /api/v1/configurations/{config_id}/components lists the configuration’s components and their names. modelId takes the model name, ScalaRoceNic, or its id from GET /api/v1/components.
Servers that need different NIC settings need different NIC components, each added to its own server component. The applications that run over the NIC are the Chakra workload and the Scala RDMA application.

Change values in a configuration

PATCH /api/v1/configurations/{config_id}/components/{component_name}/parameters merges a patch into the typedParameters of the component named component_name in the configuration; GET /api/v1/configurations/{config_id}/components lists the configuration’s components and their names. Set CONFIG_ID to the configuration’s ID and NIC_NAME to the name of the NIC component you are changing. A patch changes only the component it names, and so every server that carries that NIC component. The patch repeats the nesting of the component’s typedParameters, down to each attribute you change, as nested objects, one per name in the attribute’s path:
  • Only keys the component already has can be updated. An unknown key returns 400.
  • Each attribute’s type must match the stored type, or the request returns 400. The request also returns 400 for an empty patch, or when a nested object is sent where an attribute is expected, or the reverse.
  • The value and the unit you send replace the stored ones, so send the unit with every dimensional value.
  • A list attribute’s value is a string with its square brackets and exactly eight entries, each made of letters, digits, ., _, +, or -, for example "value": "[0.7, 0.7, 0, 0, 0, 0, 0, 0]". A list in any other form returns 400.
  • Where an attribute has enum values, its value must be one of them, or the request returns 400.
  • A 200 response returns the component’s full, updated typedParameters.
This example lowers the PFC thresholds of classes 0 and 1 to 70% (Xoff) and 30% (Xon) of each receive pool, and shortens the transport timer to 16 ms:
A NIC the platform added carries every attribute at its Default, so a patch only needs the attributes you change. For a NIC whose typedParameters you supplied yourself, see How to read the tables. Global simulation parameters, such as NDStatsReportInterval and the link MTU, Mtu in the GenericNetDevice section of DefaultNetworkParameters (4,184 bytes on the platform), are not attributes of this model; change them with PATCH /api/v1/configurations/{config_id}/parameters.

Configuration rules that stop a simulation

A configuration write returns 400 when a value breaks the rules in Change values in a configuration, when a dimensional value has a unit its type does not accept, when a uint is negative or fractional, when LaneCount is outside 1 to 16, or when a bool is neither true nor false. The NIC checks these rules before the simulation starts, and stops the run when one is broken:
  • An ingress or egress PoolAllocationVector has an entry that is not a number, has a negative entry, or has no non-zero entry.
  • An entry of WRRQueueWeights or QuantaValue is not a whole number, or an entry of PFCEnableVector, PfcStaticXoffThreshold, or PfcXonResumeThreshold is not a number.
  • MSS is outside 1 to 9,216 bytes, or MSS + 58 bytes is not smaller than the configuration’s Mtu. With the platform’s 4,184-byte Mtu, the largest MSS is 4,125 bytes.
  • LaneCount is outside 1 to 16.
  • A dimensional value has no number, is negative, or has a unit its type does not accept, or a timeval is finer than 1 ps.
  • A server with a Scala RoCE NIC runs an application other than the Chakra workload or the Scala RDMA application.
  • A switch in the topology has UETPolicyEnabled set to true. That policy assigns traffic classes from codepoints the Scala RoCE NIC does not send (Buffer under the UET policy).