ICACT20250056 Slide.20
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Thank for listening !
|
|
ICACT20250056 Slide.19
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This article presents a comprehensive architecture for processing DPDK flow rules in hardware offload applications, integrating both firmware and FPGA hardware. The architecture supports up to 8 Rx and 1 Tx rule tables per Ethernet port, with 2048 wildcard matches and 16,384 exact match entries per table. It achieves a maximum throughput of 100 Gbps, with a rule insertion rate of 204 million rules per second for exact matches and 18 million rules per second for wildcard matches, laying a solid foundation for offload hardware applications. Future optimizations will focus on expanding the number of tables and enhancing flow rule handling, addressing the growing needs of modern networks and complex hardware offload applications, ultimately improving the performance and efficiency of smart network devices.
|
|
ICACT20250056 Slide.18
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The architecture supports 9 Rule Tables (8 for Rx and 1 for Tx) and 165,888 flow rules while using minimal resources. This efficiency enables the development of additional packet processing blocks or expansion for more flow rules. The system achieves a throughput of 75 Gbps for 64-byte packets, increasing to 100 Gbps per port for packets of 128 bytes or more. The insertion rate for flow rules is impressive: 203.32 million rules per second for exact rules and 18.6 million rules per second for wildcard rules. The Wildcard Rule Table uses memory to store rules, which requires writing to the entire table for each insertion. In contrast, the Exact Rule Table uses a hash function to store rules at specific addresses, leading to a higher insertion rate.
|
|
ICACT20250056 Slide.17
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
To evaluate the design's effectiveness, third-party applications, including DPDK's l3fwd, were used. The rule table structure followed Meng Sha et al.'s methodology, and the l3fwd application was modified to support configuring rte_flow rules in both single and burst modes for wildcard and exact matches. The match-action table checks specific packet fields and executes corresponding actions. The System Under Test (SUT) includes a Supermicro server and AMD Alveo U200 NIC card, connected to a packet generator server that measures throughput and packet loss as traffic flows through the system.
The match-action table, consisting of five tables checking specific packet fields (e.g., source MAC, Ethernet type), executes corresponding actions (e.g., drop, remove VLAN header, calculate checksum). Next slide is performance results.
|
|
ICACT20250056 Slide.16
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In performance section, First I will describe the experimental setup, and then I will present the performance results.
|
|
ICACT20250056 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Our implementation consumes only 38.4% of the BRAM resources and 35.1% of the LUT on the AMD Alveo U200 board while supporting up to 165,888 rules (across 9 Rule Tables, each comprising 2048 wildcard rules and 16,438 exact rules). In the following slides, I will present the evaluation methods and the results achieved.
|
|
ICACT20250056 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
For wildcard rules with match fields in the form of (min, max), these rules are translated into individual entries configured in the wildcard rule table on the NIC. Significantly reduces the number of rule sets in the wildcard rule table without altering the application logic of the rules. The examples to perform algorithms show in Figure. The algorithms pseudo code is show below. Figure provides a visual example of the algorithm in action. Consider a flow rule where the ipv4_src field falls within the range 192.168.0.84 to 192.168.0.96. To cover this range, 13 exact match rules would typically be required. However, by applying the algorithm, only three rules are needed, demonstrating its efficiency. In the next slide, i will outline the features and resources on the FPGA.
|
|
ICACT20250056 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
. This figure describes the communication between software, firmware, and hardware, where DPDK applications use the rte_flow API to offload packet processing to hardware. The VTL Driver converts API parameters into hardware configuration data, which is transmitted via the Axi-Stream bus. The Rule Parse block analyzes flow rules and directs them to the appropriate handler (Wildcard or Exact Match). The hardware configuration is then sent to the NIC card through the PCIe interface, with the VFIO-PCI Driver bypassing the Linux kernel space. For wildcard flows in min-max form, I developed an algorithm to break down min-max flows into individual flows and configure them into the table. Next slide, I will present this algorithm.
|
|
ICACT20250056 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
There are two main TCAM implementation methods: logic-gate-based and memory-based TCAM. In logic-gate-based TCAM, FPGA logic resources store and compare key-mask pairs, offering high insertion throughput but consuming significant resources as rule numbers increase. Memory-based TCAM uses memory like Block RAM or Lookup Table RAM to store keys and masks, offering better memory efficiency but lower insertion throughput. This can be improved with "burst" insertion mode. Memory-based TCAM is ideal for Wildcard Tables due to its lower resource usage and flexibility, making it suitable for scalable network systems. In the next section, I will present firmware architecture and interface between FPGA và firmware.
|
|
ICACT20250056 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Exact_keys require a complete match of packet header fields, ensuring precise identification of data streams, while Wildcard_keys provide flexibility by allowing rules to apply to multiple packets. Exact_keys typically use conventional memory, while Wildcard_keys often use TCAM memory. Using TCAM consumes significant FPGA resources because it can compare multiple bits in a key simultaneously, enabling it to handle complex and flexible rules. However, TCAM requires more hardware than other search methods like SRAM or DRAM, leading to higher logic and memory usage. In the next slide, I will describe the implementation of TCAM in FPGA.
|
|
ICACT20250056 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The figure illustrates how header fields are transformed into keys. Before these fields are combined to create keys for the Rule Table, each field passes through the Trans TCAM block. The next slide will explain the operation of the flow matching process.
|
|
ICACT20250056 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The size of the keys and the number of rules in the Rule Table significantly affect FPGA resource usage, such as logic gates and memory. Reducing key size is essential for minimizing resource consumption, enabling the NIC to support more wildcard rules for large-scale applications. One approach to reducing key size is to focus on the specific values used by an application. For example, in an Open vSwitch application, only a few Ethernet header fields (like IPv4, IPv6, ARP, and VLAN protocols) are needed, allowing these values to be represented more compactly.
|
|
ICACT20250056 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In this slide, I present the hardware architecture implemented on the Xilinx Alveo U200. The packet enters the RX path and first passes through the Ingress Adapter, where its length is calculated and validity is checked. Metadata, including this information, accompanies the packet during processing. The Header Parser extracts necessary header fields from OSI layers 2, 3, and 4, ensuring compatibility with rte_flow API patterns. The Trans TCAM Rx module consolidates the extracted fields into a key, which is used to query Rule Tables for the appropriate actions. This same process is applied to the TX path during transmission. The Trans TCAM and Rule Table modules play a crucial role in flow rule processing. In the next slide, I will explain the operation of the Trans TCAM.
|
|
ICACT20250056 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In this section, I will provide an overview of the proposed architecture. First, I will introduce the FPGA-based design we've developed to optimize flow rule processing in DPDK. Then, I'll dive into the hardware design, explaining the key components and how they are interconnected. Finally, we'll explore the firmware layer of the architecture, focusing on its integration with the FPGA hardware."
|
|
ICACT20250056 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
As the demand for high-speed data transmission continues to grow, optimizing flow rule processing becomes critical to maintaining network efficiency. Traditional CPU-based solutions face scalability and performance challenges when processing large numbers of flow rules in real-time. As a solution, we propose the use of FPGA (Field-Programmable Gate Array) technology to accelerate this process and significantly improve overall system performance. While DPDK provides an efficient framework for high-speed packet processing, there is a notable gap in FPGA architecture support for offloading flow rule processing using the rte_flow API. FPGA architecture as well as hardware and software communication interfaces will be presented in the following slides
|
|
ICACT20250056 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The table show that both FPGA-based and ASIC-based SmartNICs have their advantages, depending on the use case. FPGA-based SmartNICs are ideal for environments that require flexibility, scalability, and rapid adaptation to new protocols or features, whereas ASIC-based SmartNICs excel in high-performance, task-specific applications where efficiency and low power consumption are paramount. In the context of our paper, we focus on utilizing the FPGA-based SmartNIC due to its flexibility and scalability. In the next slide, I will explain my motivation for writing this paper.
|
|
ICACT20250056 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Data Plane Development Kit (DPDK) is a high-performance packet processing framework widely used in network applications. It provides the infrastructure needed to accelerate packet processing tasks, enabling faster, more efficient handling of network traffic.
Key Features of DPDK:
1. Kernel Bypass for Low-Latency, High-Speed Networking
DPDK enables direct access to hardware resources by bypassing the kernel, reducing the overhead typically caused by the operating system’s networking stack..
2. Poll Mode Drivers (PMD) for Efficient Packet Handling
DPDK uses Poll Mode Drivers (PMD) to handle packet reception and transmission instead of relying on interrupts, enabling much faster and more efficient packet processing.
3. Multi-core Scaling
DPDK allows for multi-core scaling, which means that packet processing tasks can be distributed across multiple CPU cores.
4. Zero-Copy Buffers
DPDK implements zero-copy buffer management, which eliminates the need for data to be copied between the user space and kernel space. This reduces memory access overhead and speeds up the data transfer process, enhancing the overall efficiency of packet processing.
RTE Flow is a framework in DPDK designed for efficient, rule-based packet processing. By utilizing hardware acceleration, such as smartNICs, it offloads tasks from the CPU, enabling fast and scalable rule matching and action execution, which ultimately improves performance and reduces CPU load. In the next slide, I will provide an overview of the different types of smartNIC-based hardware architectures.
|
|
ICACT20250056 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In Introduction & Background section, I will overview of DPDK & RTE Flow, SmartNIC and Motivation of our paper.
|
|
ICACT20250056 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
My presentation today is structured into 4 key sections, which will guide you through the introduction, design, and evaluation of the proposed FPGA architecture for DPDK flow rules processing. Here's a quick overview of what I will cover:
1. Introduction & Background
I will begin by providing context on the growing need for efficient flow rule processing in modern network systems and discuss the limitations of traditional CPU-based solutions. I will also highlight the role of DPDK in accelerating packet processing and introduce FPGA as a viable solution.
2. Proposed FPGA Architecture
In this section, I will present the core of our paper — the FPGA-based architecture we’ve designed to enhance flow rule processing in DPDK.
3. Performance
I will describe the experimental setup used to evaluate the performance and the performance results of our FPGA architecture.
4. Conclusion & Future Work
Lastly, I will conclude the presentation by summarizing the key findings of our paper and outline potential future work.
Let start Introduction & Background section
|
|
ICACT20250056 Slide.01
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Good morning, every one. It is a great pleasure to be here today at the ICACT 2025 conference. I would like to begin by introducing our paper titled "Efficient FPGA Architecture for DPDK Flow Rules Processing". This paper is the result of collaborative work by our team at Viettel, a leading telecommunications company in Vietnam.
The authors of this paper are Vo Thanh Van, Nguyen Phu Lam, Nguyen Nhat Truong, Nguyen Quang Phuong, Vu Tuan Duc, and Le Ngoc Toan, engineers at Viettel, with a strong background in telecommunications and network systems.
Throughout this presentation, I will walk you through the introduction, propose FPGA architecture, experimental setup, performance results, and conclusions of our paper.
|
