Packet Trimming Deep Dive - Part II

Receive Interface Group (Rx IFG)

Ingress Pre-Processing and Integrity

The Receive Interface Group (Rx IFG) is the ingress pre-processing stage that handles the incoming Ethernet bitstream before the packet enters the Packet Processing Array (PPA) of the Receive Network Processing Unit (Rx NPU) in the Cisco Silicon One architecture.

Processing begins at the Rx MAC. The Rx MAC reconstructs (“delimits”) the Ethernet frame from the Physical Coding Sublayer (PCS) bitstream and verifies frame integrity by computing a Frame Check Sequence (FCS) using the CRC-32 algorithm. If the computed FCS does not match the received FCS value, the frame is considered corrupted and is dropped immediately at ingress. If the CRC check succeeds, the frame is admitted for further processing. 

Shallow classification and Traffic Class mapping

After frame validation, the Rx IFG identifies the Ethernet MAC header and detects the presence of IEEE 802.1Q VLAN tags. The Rx IFG performs shallow classification to efficiently manage hardware resources before deeper protocol parsing and forwarding decisions are executed in the Rx NPU. When an IEEE 802.1Q VLAN tag is present, the Rx IFG extracts the Priority Code Point (PCP) bits from the VLAN tag and maps them to an Internal Traffic Class (ITC). Based on this mapping, the frame is placed into a specific port-based local hardware FIFO queue.

If the frame does not carry a VLAN tag, or if no usable CoS information is available, the frame is assigned to a default Internal Traffic Class and buffered in a standard port-based FIFO queue.

At this stage, no forwarding lookup is performed; the purpose is limited to frame validation and shallow classification.

Port-based FIFO queues and packet buffering

The small port-based FIFO queues serve two purposes.

First, they provide prioritization for writing packet data into shared SRAM. Prioritization is required because a large number of packets, originating from many ingress ports and representing thousands of concurrent flows, may arrive simultaneously at the Rx IFG. The FIFO queues regulate this contention and determine the order in which packets are admitted into shared memory based on their assigned Internal Traffic Class.

Second, in parallel with the memory write operation, the Rx IFG generates a compact packet metadata structure known as the Packet Header Vector (PHV).

Packet Header Vector (PHV) Creation

The Packet Header Vector summarizes essential information about the packet without requiring full packet inspection. It is created in the Rx IFG to offload basic packet characterization from the Rx NPU parser, thereby reducing processing overhead in the programmable pipeline and enabling higher sustained packet rates. The PHV includes metadata such as:

• Ingress interface and timestamp, and Packet length
• Pointer to the packet’s cell chain in memory
• Internal Traffic Class (ITC), VLAN ID, and EtherType
• Router MAC hit indication

The Rx IFG operates as a pattern-matching engine rather than performing linear, sequential parsing of the entire packet. For example, when the EtherType field indicates IPv4 (0x0800), the Rx IFG recognizes that the IP Protocol field, used to identify the transport protocol such as TCP or UDP, is located at a fixed offset within the IPv4 header. It can therefore extract that field directly without scanning the header byte by byte.

Similarly, when an IEEE 802.1Q VLAN tag is present, the Rx IFG accounts for the additional header field and adjusts the parsing offset accordingly to locate the correct EtherType position before proceeding with further field extraction.

The Router MAC field in the PHV is a hit indicator that signals whether the destination MAC address matches one of the switch’s configured router MAC addresses. A positive match indicates that the packet is addressed to the switch itself and allows the Rx NPU to immediately invoke Layer 3 processing logic, bypassing Layer 2 forwarding paths.

Handoff to the Rx NPU

Once the PHV is constructed, it is dispatched to one of the many Run-to-Completion (RTC) cores in the Packet Processing Array (PPA) of the Rx NPU. Packets belonging to the same flow are consistently steered to the same RTC core to preserve packet ordering. All other flows arriving in parallel are distributed across the remaining RTC cores to maximize throughput and parallelism.

Figure 9-2: Receive Interface Group Processes.