NXP Semiconductors Product Brief: S32G PFE Product Brief

1. Software Product Overview

The Packet Forwarding Engine (PFE) software (SW) consists of the following SW components for the S32G Hardware (HW) Platform:

• PFE Firmware
• Ethernet Driver
• Configuration API - FCI (Fast Control Interface)
• Management daemon - CMM (Conntrack Monitor Module)

All components, or specific ones, are subject to integration with the target environment, represented by the target HW platform, operating system (OS), OS-provided networking components (Networking Stack, firewall), and related user applications.

Firmware

Firmware is a software component running within the PFE. Each packet reaching the PFE (ingress/egress) is processed by the firmware, which is responsible for packet classification, routing, modifications, and supporting functions. Firmware is under the control of NXP and can be modified/extended as required by target use cases to add specific features related to Ethernet traffic processing. The firmware is delivered in a binary form.

Ethernet Driver

The Ethernet driver is, in general, an OS-specific component and consists of three main functional blocks:

• Platform driver: This covers initial PFE HW bring-up, configuration, firmware upload, and management of PFE HW components. It acts as a low-level PFE driver providing interface to the hardware (including firmware).
• Data path management: Tasks related to Ethernet data traffic management, including passing packets between PFE and the networking stack. This includes the implementation of the Host Interface (HIF) driver and connection with the networking stack.
• Control path management: Functionality related to PFE engine configuration, FCI. The driver runs within the target host OS environment and connects the PFE with the networking stack. It provides access to physical Ethernet interfaces via exposing endpoints to the OS and implements the control path domain for configuration and monitoring of PFE hardware and firmware resources. The driver can be used in its full form or as a simple HIF driver if the host CPU does not need to run the full driver but still requires access to the data path domain (multi-core environment).
• Master-Slave Runtime: The driver can run in multiple instances within the same system to allow sharing the PFE provided connectivity using dedicated host interfaces for dedicated CPU cores.

Configuration API

To allow host applications to configure PFE features, the PFE SW provides a configuration API called "Fast Control Interface (FCI)." It is an io-ctl-like interface implemented as a user-space library and a kernel-space part running within the driver. Functions like fci_open(), fci_write(), fci_cmd(), or fci_query() provided by the LibFCI are available to pass commands with arguments and receive responses. The Configuration API implementation is closely coupled to the platform driver and is therefore OS-dependent.

CMM

CMM is a host user-space demo application developed to simplify the configuration of some PFE features, like L3 Router. It runs within the host OS and monitors the networking stack. When it detects an Ethernet flow that could be potentially fast-forwarded (routed by PFE instead of the host CPU), it uses LibFCI to configure the PFE accordingly. Users do not need to program their own management application and configure the PFE directly; instead, they configure the routing subsystem using native OS-provided interfaces. CMM could potentially be extended to automatically configure IPsec offload or L2 bridging. For CMM availability, please contact an NXP representative.

2. Software Content

This chapter covers a basic functional description of features supported by the PFE block and related SW stack (firmware, drivers, APIs).

Datapath Endpoint

This is standard data flow functionality provided by the Firmware and Ethernet driver via endpoints (PFEn) exposed to the OS and corresponding to particular physical interfaces (MACn) of the PFE. It covers:

• Initial PFE platform configuration (clocks, pins, memory, firmware, ...).
• MAC address filtering per physical interface.
• Optional CRC generation and verification offload (IPv4/IPv6 TCP/UDP/ICMP, FCS).
• Reception of packets via physical interfaces and providing them to the host networking stack via endpoints.
• Transmission of packets originating from the host networking stack via physical interfaces.

Figure 2. Driver and Interfaces depicts the interaction between CPU, PFE, and interfaces.

IPv4/IPv6 Router

The IPv4/IPv6 Router is a dedicated feature to offload the host CPU from tasks related to forwarding specific IP traffic between two physical interfaces. Normally, ingress IP traffic is passed to the host CPU running the TCP/IP stack, which is responsible for routing the packets. Once the stack identifies that a packet does not belong to any local IP endpoints, it performs a lookup in the routing table to determine how to process such traffic. If the routing table contains an entry associated with the packet (5-tuple search), the stack modifies and forwards the packet to another interface to reach its intended destination node.

The PFE can be configured to identify flows that do not need to enter the host CPU using its internal routing table, ensuring that the correct packets are forwarded to the correct destination interface. The following features support the forwarding functionality:

• Routing table lookup: The PFE performs routing table lookup based on information parsed from ingress packet header fields (5-tuple: SRC/DST IP, SRC/DST port, protocol). The lookup operation's output is an entry containing instructions programmed by the user, specifying actions to be performed on the matching packet (destination interface, NAPT configuration, etc.).
• NAPT: If specified, the PFE performs packet modification according to NAPT setup. It updates addresses and/or ports as requested by the configuration within the routing table entry.
• TCP end of connection monitoring: The PFE implements monitoring of fast-forwarded flows. If a SYN, FIN, or RST packet is detected, the PFE sends a notification to the host application, where it can be appropriately handled (e.g., remove the flow from the local table, update the firewall).
• Packet forwarding to destination interface: Once a packet is routed and modified, it is forwarded to the destination interface.

L2 Bridge (Switch)

The L2 Bridge functionality covers forwarding of packets based on MAC addresses. It allows moving bridging-related tasks from the host CPU to the PFE, thus offloading the host-based networking stack. The L2 Bridge feature represents a network switch device implementing the following functionality:

• MAC table and address learning: The L2 bridging functionality determines to which interface an ingress packet shall be forwarded. For this purpose, a network switch device implements a bridging table (MAC table, also known as FDB - Forwarding Data Base), which is searched to get the target interface for each packet entering the switch. If received, the interface on which the packet was received is added as "learned." The destination MAC address of an ingress packet is then used to search the table to determine the target interface.
• Aging: Each MAC table entry gets a default timeout value once learned. This timeout value decreases over time until it reaches zero. Entries with a zero timeout value are automatically removed from the table. The timeout value is reset each time the corresponding table entry is used to process a packet.
• Port migration: When a MAC address is seen on one interface of the switch and the entry has been created, it is automatically updated when the MAC address is seen on another interface.
• VLAN awareness: The bridge implements a VLAN table. This table is used to implement VLAN-based policies like Ingress and Egress membership. The feature includes configurable VLAN tagging and un-tagging functionality per bridge interface.

The bridge utilizes PFE HW accelerators to perform MAC and VLAN table lookups, making these operations highly optimized. The Host CPU SW is solely responsible for correct bridge configuration using the dedicated API.

Ingress QoS

Under heavy traffic conditions, a network device can experience a "congestion state." This can be caused, for instance, by internal performance limitations (e.g., limited processing bandwidth for routing large amounts of small packets or too complex/time-consuming operations), resulting in packet drops within the device's input stages. Therefore, the input interface is where Ingress QoS takes place. Its main purpose is congestion avoidance and congestion control. To support this, Ingress QoS implements the following mechanisms:

• Classification of ingress traffic into: Managed, unManaged, and Reserved.
• Weighted Random Early Drop (WRED).
• Ingress port-based rate shaper.

These mechanisms allow users to prioritize ingress traffic and ensure that high-priority traffic is received preferentially at the expense of low-priority flows.

Classification

Classification is implemented via a table where the user can program data flow parameters (L2/L3/L4) and specify which type of traffic (Managed, unManaged, Reserved) the flow belongs to. Optionally, certain flows can be classified as "To be dropped" to identify and terminate malicious flows within the ingress block, without reaching subsequent processing stages.

WRED

After the classification stage, Ingress QoS implements the WRED algorithm to drop low-priority traffic when the PFE reaches a congestion state. There are multiple configurable zones with different thresholds and drop probabilities. The higher the zone, the higher the drop probability used by WRED.

Figure 3. WRED Zones illustrates the different zones and their associated actions.

Shaper

Frames passing the WRED are routed to the last Ingress QoS component: the port-based rate shaper. This shaper is implemented for the complete port traffic. It uses a standard token bucket algorithm to count the number of bytes to be admitted. The user can configure its parameters and leverage the maximum data rate (64 kbps to 2.4 Gbps) to be received by the particular ingress interface.

Ingress QoS also provides statistics to inform the user about the number of drops at particular stages.

Egress QoS

Egress QoS is located within the egress stage of the PFE packet processing pipeline. It is implemented on a per-interface basis using a set of queues (8x), schedulers (2x), and shapers (4x) with configurable topology.

Figure 4. Egress QoS Topology Example shows a typical Egress QoS topology.

Queue

A Queue is an entity representing an input FIFO of the Egress QoS block, used to temporarily hold packets to be transmitted. It can also be understood as an interface through which packets belonging to a certain traffic class are transmitted. It has a limited size; once this limit is reached, all attempts to enqueue additional packets into the full queue result in "tail drop behavior," where new packets are dropped. Packets are written to particular queues by the PFE classifier engine.

The mapping between traffic class and destination queue is defined by a configurable priority mapping table. The user can configure the PFE to map packets to queues based on the TOS/TrafficClass value from the IPv4/IPv6 header. Packet transmission from queues is managed using schedulers and various scheduling algorithms to arbitrate the queues.

Scheduler

A Scheduler is a component of Egress QoS responsible for traffic aggregation from multiple queues. Its main task is to select the next packet from a queue for transmission. Schedulers implement the following scheduling disciplines:

• Simple Round Robin (RR): Each queue is configured with a specific percentage of link speed as its weight. Quota and deficit parameters are used to guarantee committed bandwidth and a fair chance for each queue.
• Deficit Weighted Round Robin (DWRR): Similar to RR, with weighted queues.
• Priority Queuing (PQ): Each queue is assigned a priority. The high-priority queue must be emptied before accessing the lower-priority queue.

The maximum number of inputs assigned to a single scheduler is 8.

Shaper

Egress QoS implements 801.Q Credit Based Shapers. Their purpose is to space out frames as much as possible, reduce bursting during data peaks, and control the maximum egress data rate (in data rate or packet rate units). Generally, shapers operate with configurable clock ticks. With each tick, the internal credit value is updated according to configured parameters. When an input queue has data and the credit value is positive, the queue is serviced, and the credit value is decreased. If the credit value is negative, the input queue will not be serviced. Users can configure the position and parameters of the shaper according to application needs.

Flexible Parser and Flexible Router

The PFE classifier performs a lookup on standard L2/3/4 header fields to make a routing decision. The flexible parser allows proprietary fields to be part of the routing decision. A similar scheme is implemented in HW for the GMAC on S32G. For PFE, this is a firmware-based solution.

Flexible Filter

Flexible Filter allows users to define a table of rules associated with certain actions. Each rule specifies data, data position, and a mask to be matched with the content of an Ethernet frame. When a frame payload matches the rule, the associated action (accept, reject, jump to another rule) is executed. This enables routing CAN frames to Ethernet and vice-versa with zero host intervention, all running on the M0+ LLCE core.

2.1. Premium Features

IDPS

Intrusion detection and prevention system extensions, in cooperation with the Argus PFE Firmware API, have been created for the customer library. This allows customer-specific classification of packet flows at the firmware level, offering performance boosts for customer applications and added flexibility. Please contact an NXP representative for more details on IDPS.

IPsec

The base firmware includes IPsec support to offload protected packets to the HSE via the utility PE within PFE. The base firmware does not utilize the additional IPsec protocol acceleration feature provided by the HSE (i.e., IPsec ESP encapsulation and decapsulation). Firmware modifications leverage this feature to improve the performance of the solution.

3. Supported Targets

Please refer to the Release Notes document for release-specific details.

• Supported target: S32G2 and S32G3 processors.

4. Quality, Standards Compliance and Testing Approach

The S32G PFE Firmware, MCAL, and QNX SW products are developed according to NXP Software Development Processes, which are Automotive-SPICE, IATF16949, and ISO 9001 compliant.

5. Document Information

Table 1. Sample revision history