Port cross-connect on XISA™

A peek under the hood

Ever wonder about the fundamental mechanisms that drive network switches? While configuring high-level networking might seem abstract, the core of packet forwarding often relies on low-level microcode (uCode) instructions. This is a simplified look at that, based on Xsight Labs' exposed X-Switch Instruction Set Architecture (XISA), using a very basic use case: a simple cross-connect between two ports.

A simple cross-connect forwards incoming packets from an ingress port to a corresponding egress port without modifying the packet. The control plane program populates an Ingress Port lookup table that maps an ingress port to a specific egress queue on the desired egress port, making the association configurable at run time rather than pre-determined.

To send a packet out of a given egress port, we direct it to one of the egress queues associated with that port. X-Switch ports typically have multiple egress queues to facilitate packet prioritization. To determine the appropriate egress queue number for a packet received on a specific ingress port, a lookup mechanism is necessary. We could build a custom table for this, but we can instead leverage the special Ingress Port table inherently available on the device. In that table the ingress port acts as the key, and the corresponding egress queue number is the value. The control plane populates it with the desired egress queue number for each ingress port.

Once a packet reaches the Match-Action Processor (MAP), the result of the lookup in the Ingress Port table is automatically available in MAP register R1. The MAP microcode retrieves the egress queue number ID (QID) from that result. The QID indicates to the hardware where to send the packet.

Figure 1. Simple uni-directional cross-connect example

Ingress Port table (example population)

Examining the microcode: a simplified XISA flow

Packet switching is processed via the XISA, first via the Parser, then via the MAP.

Parser uCode

For a simple cross-connect example, the Parser processing is simply to HALT.

Figure 2. Parser code

1{2      special_entry_points3      ingress: entry_point_ethernet4}5entry_point_ethernet:6HALT

Breakdown

• special_entry_points — defines the parser's initial transition table, determining the starting point for packet processing based on the packet's arrival path (Ethernet, Host CPU or other). An ethernet entry point is specified in our example, directing all standard packets arriving through the ingress path to begin processing at the entry_point_ethernet label.
• entry_point_ethernet — marks the beginning of the processing logic arriving at ingress.
• HALT — this Parser instruction immediately stops any further parsing of the packet header at this stage. No packet inspection is done at this point. The packet is now ready for MAP processing.

MAP uCode

The MAP uCode prepares information needed for sending out, using MAP registers. Once the registers are prepped, a send instruction ferries the packet descriptor to an egress queue.

Note: There are 14 MAP registers (R0 to R13), each holding four 32-bit words (0–3), supporting big-endian architecture. For example, R1.3 specifies the fourth word of the R1 MAP register, bits 0 to 31.

In the microcode example below, lines 2 to 4 prepare the registers for the egress SENDOUT instruction in line 5. The 16-bit QID field (part of the Ingress Port Entry result value) will have been preloaded into MAP Register R1 Word 0 (R1.0), at offset 16, by the HW accelerator.

The SENDOUT instruction uses two registers as its operands.

• The first operand must include the QID and FrameDelta fields, loaded into a MAP register at these locations: QID at offset 0 of the lowest Word (Word 3); FrameDelta at offset 0 of the second lowest Word (Word 2).
• The second operand includes additional header editing instructions (zeroed out for this example).

Lines 2 and 3 prepare SENDOUT's first operand; line 4 prepares its second operand.

Figure 3. MAP assembly code

10   ingress:2132   MOVI R1.2, 043   CONCAT.CD R1.3, 0, R1.0, 16, 1654   MOVI.CD R0.3, 065   SENDOUT.H R1, R0, 0

Breakdown

• ingress: — this pre-defined label name determines the starting point for packet processing in the MAP, upon ingress (there may be other entry points).
• MOVI R1.2, 0 — the program will expect to find the FrameDelta field info in Word 2 of the register (here R1) later in the SENDOUT instruction. This is the number of bytes added to or removed from the header. Since this program does not modify the header, we load 0 into that word using the Move Immediate (MOVI) instruction, indicating that no header has been added or removed.
• CONCAT.CD R1.3, 0, R1.0, 16, 16 — crucial for forwarding. It prepares packet fields for sending: the QID is currently located in R1.0, offset 16 (placed there by the HW accelerator); the subsequent SENDOUT command expects to find the QID in R1.3 at offset 0. So we use the CONCATenation instruction with a clear destination extension (.CD) to clear R1.3 and then place the 16-bit QID field from R1.0 in R1.3.

Instruction syntax breakdown: CONCAT

• MOVI.CD R0.3, 0 — disables any header adjustments on the egress port, clearing the entire register R0 (not just Word 3 of R0).
• SENDOUT.H R1, R0, 0 — sends the packet to an egress queue and halts processing for this packet. The packet header is an implicit operand of the instruction.

Instruction syntax breakdown: SENDOUT

Beyond the simplicity: XISA's potential

While this cross-connect example demonstrates a fundamental operation in a clear and concise manner, XISA is capable of handling much more sophisticated networking tasks. Any standard routing or bridging feature, and more importantly any unique or customer-driven feature, can be implemented due to the X-Switch's extreme flexibility and programmability. For more information, contact us.

XISA (the X-Switch Instruction Set Architecture) is Xsight Labs' open instruction set for programming packet processing on the X-Switch family, published under the Mozilla Public License version 2. Programs run across two stages: a Programmable Parser that identifies packet headers, and a Match-Action Processor (MAP) that performs lookups, edits and forwarding.