Xử lý gói tin tốc độ cao với DPDK trên Linux: Cài đặt và xây dựng ứng dụng mạng đầu tiên

Table of Contents

Khởi động nhanh: Chạy DPDK trong 5 phút

Tôi vẫn nhớ lần đầu tiên một trưởng nhóm mạng đưa cho tôi xem file packet capture với 40% packet loss ở tốc độ 10Gbps trên một máy Linux thông thường. Kernel network stack đã không thể chịu được tải. Đó là lúc DPDK xuất hiện trong bộ công cụ của tôi — và thật lòng mà nói, đây là một trong những thứ tôi ước mình đã học sớm hơn hai năm.

DPDK (Data Plane Development Kit) cho phép các ứng dụng userspace giao tiếp trực tiếp với NIC của bạn, hoàn toàn bỏ qua kernel network stack. Không xử lý ngắt, không chuyển đổi context, không sao chép gói tin giữa kernel và user space. Chỉ là tốc độ polling-mode thuần túy.

Hãy cùng thiết lập môi trường hoạt động nhanh chóng, rồi đi sâu tìm hiểu những gì thực sự xảy ra bên dưới.

Bước 1: Cài đặt DPDK

Trên Ubuntu 22.04 / các hệ thống dựa trên Debian:

# Cài đặt thư viện và công cụ phát triển DPDK
apt update
apt install -y dpdk dpdk-dev libdpdk-dev dpdk-kmods-dkms python3-pyelftools

# Xác nhận cài đặt
dpdk-devbind.py --version

Dành cho RedHat/Rocky Linux:

dnf install -y dpdk dpdk-devel rdma-core-devel

Bước 2: Cấu hình Hugepages

DPDK dựa vào hugepages để tăng hiệu quả bộ nhớ — các trang 4KB tiêu chuẩn tạo ra áp lực TLB rất lớn ở tốc độ gói tin cao. Bạn cần các trang 2MB (hoặc 1GB trên phần cứng hỗ trợ).

# Cấp phát 1024 x hugepage 2MB (= 2GB tổng cộng)
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# Giữ cài đặt sau khi khởi động lại
# LƯU Ý: Nếu GRUB_CMDLINE_LINUX_DEFAULT đã tồn tại trong file grub,
# hãy thêm tham số hugepage vào giá trị hiện có — không thêm định nghĩa thứ hai.
cat >> /etc/default/grub <<'EOF'
GRUB_CMDLINE_LINUX_DEFAULT="hugepages=1024 hugepagesz=2M"
EOF
update-grub

# Mount filesystem hugepage
mkdir -p /dev/hugepages
mount -t hugetlbfs nodev /dev/hugepages

# Xác nhận
grep HugePages /proc/meminfo

Bước 3: Gắn NIC với DPDK Driver

Đây là bước mà nhiều người thường vấp ngã. Khi bạn gắn NIC với DPDK driver (vfio-pci hoặc igb_uio), nó sẽ biến mất khỏi Linux network stack thông thường — không còn thấy eth1 hay tương tự nữa. Hãy lên kế hoạch trước.

# Liệt kê các NIC có sẵn và driver hiện tại của chúng
dpdk-devbind.py --status

# Nạp driver vfio-pci (khuyến nghị, an toàn với IOMMU)
modprobe vfio-pci

# Bật IOMMU nếu chưa bật (thêm vào grub: intel_iommu=on)
# Sau đó gắn NIC (thay 0000:03:00.0 bằng địa chỉ PCI của bạn)
dpdk-devbind.py --bind=vfio-pci 0000:03:00.0

# Xác nhận việc gắn kết
dpdk-devbind.py --status

Dùng lspci | grep -i ethernet để tìm địa chỉ PCI trước khi chạy lệnh gắn kết.

DPDK hoạt động như thế nào (Tìm hiểu chuyên sâu)

Bỏ qua phần này và bạn sẽ mất hàng giờ debug những thứ không phải là lỗi — chúng chỉ là cấu hình sai. Đây là những gì thực sự xảy ra khi DPDK xử lý gói tin ở line rate.

Poll Mode Drivers và Interrupt-Driven Networking

Linux network stack tiêu chuẩn hoạt động theo cơ chế interrupt. Một gói tin đến, NIC kích hoạt một ngắt, kernel thức dậy, sao chép từ bộ nhớ NIC vào kernel space, rồi lại sao chép tiếp vào userspace. Hai lần sao chép cho mỗi gói tin. Ở 10Gbps với frame 64 byte, đó là tới 14,88 triệu ngắt mỗi giây — CPU của bạn tốn nhiều thời gian chuyển đổi context hơn là xử lý dữ liệu gói tin thực sự.

DPDK đảo ngược hoàn toàn điều này. Một CPU core chuyên dụng chạy một vòng lặp polling chặt chẽ (PMD — Poll Mode Driver), liên tục hỏi NIC: có gói tin nào không? Không ngắt, không chuyển đổi context, không có sự tham gia của kernel. Core đó chiếm 100% CPU, nhưng bạn nhận được thông lượng xác định ở line rate.

# Xem điều này thực tế — một DPDK PMD core sẽ hiển thị 100% CPU usage
top -H  # Tìm các thread tiến trình l2fwd hoặc testpmd của bạn

Environment Abstraction Layer (EAL)

EAL là lớp runtime mà mọi ứng dụng DPDK phụ thuộc vào — một OS tối giản bên trong OS xử lý các công việc đặc thù của nền tảng để code ứng dụng của bạn không cần phải làm. Nó quản lý:

Phân bổ và ghim CPU core (hỗ trợ NUMA)
Quản lý memory pool (mempools được hỗ trợ bởi hugepages)
Khởi tạo thiết bị PCI và gắn driver
Trừu tượng hóa đa nền tảng (Linux, FreeBSD)

Điều đầu tiên bất kỳ ứng dụng DPDK nào cần làm — trước khi mở port, tạo mempools, hay spawn thread — là khởi tạo EAL:

int main(int argc, char *argv[]) {
    // Khởi tạo EAL — phải chạy trước tiên
    int ret = rte_eal_init(argc, argv);
    if (ret < 0)
        rte_exit(EXIT_FAILURE, "Khởi tạo EAL thất bại\n");

    // Logic ứng dụng của bạn theo sau
    // ...
    return 0;
}

Kiến trúc bộ nhớ: mbufs và mempools

Các gói tin trong DPDK được biểu diễn dưới dạng cấu trúc rte_mbuf, được cấp phát từ các memory pool đã được phân bổ trước (rte_mempool). Việc phân bổ trước loại bỏ hoàn toàn malloc/free khỏi hot path. Ở 14Mpps, chỉ một lần malloc cho mỗi gói tin cũng gây ra độ trễ microsecond tích lũy thành các đột biến độ trễ rõ ràng dưới tải.

// Tạo mempool cho bộ đệm gói tin
struct rte_mempool *mbuf_pool = rte_pktmbuf_pool_create(
    "MBUF_POOL",      // tên
    8192,             // số lượng mbufs
    256,              // kích thước cache per-core
    0,                // kích thước private của ứng dụng
    RTE_MBUF_DEFAULT_BUF_SIZE,
    rte_socket_id()   // NUMA socket
);
if (!mbuf_pool)
    rte_exit(EXIT_FAILURE, "Không thể tạo mbuf pool\n");

Xây dựng và chạy ứng dụng DPDK đầu tiên

Cách nhanh nhất để thấy DPDK hoạt động là dùng ví dụ l2fwd (Layer 2 forwarder) có sẵn. Nó chuyển tiếp gói tin giữa các cặp port — đơn giản, nhưng minh họa đầy đủ PMD pipeline.

Build các ứng dụng ví dụ

# Tìm thư mục ví dụ DPDK
ls /usr/share/dpdk/examples/

# Build l2fwd
cd /usr/share/dpdk/examples/l2fwd
make RTE_SDK=/usr/share/dpdk RTE_TARGET=x86_64-native-linuxapp-gcc

# Hoặc dùng meson/ninja (DPDK >= 20.11)
meson build
ninja -C build

Chạy l2fwd

# Tham số EAL đặt trước --, tham số ứng dụng đặt sau
# -l 0,1: sử dụng core 0 và 1
# -n 4: 4 kênh bộ nhớ
# -- -p 0x3: bật port 0 và 1
sudo ./build/l2fwd \
    -l 0,1 \
    -n 4 \
    -- \
    -p 0x3 \
    --portmask=0x3

Thống kê mỗi port cập nhật mỗi giây trong terminal. Với traffic generator gửi tới NIC đã gắn, hãy kỳ vọng tốc độ chuyển tiếp từ 5–14Mpps tùy thuộc vào kích thước gói tin, với packet loss gần bằng không khi cài đặt đã được tinh chỉnh.

Kiểm tra với testpmd (Không cần code tùy chỉnh)

Đừng viết một dòng code ứng dụng nào cho đến khi testpmd xác nhận môi trường của bạn hoạt động tốt. Nó kiểm tra hugepages, driver binding và khả năng tương thích NIC trong một lần — nếu không nhận được gói tin, không có lượng code tùy chỉnh nào có thể khắc phục vấn đề cơ bản.

# Chạy ở chế độ rxonly để đo thông lượng nhận thuần túy
sudo dpdk-testpmd \
    -l 0-3 \
    -n 4 \
    -- \
    --nb-cores=2 \
    --nb-ports=1 \
    --rxq=2 \
    --txq=2 \
    --forward-mode=rxonly

# Bên trong dấu nhắc testpmd:
testpmd> show port stats all
testpmd> start

Mẹo thực tế từ các triển khai thực tế

Việc chạy được DPDK chỉ mất một buổi chiều. Nhưng làm cho nó thực sự đạt hiệu năng mới là chỗ hầu hết kỹ sư mất cả tuần. Kịch bản điển hình: bạn chỉ đạt 50–60% thông lượng lý thuyết, nghĩ rằng NIC là nút thắt, rồi bắt đầu săn lùng thông số phần cứng. Thường thì vấn đề nằm ở một trong ba thứ — PMD core bị gián đoạn bởi OS scheduler, packet buffer vượt ranh giới NUMA, hoặc quá ít RX queue cho số lượng core.

Cô lập CPU khỏi Linux Scheduler

Các PMD core của bạn không được bị gián đoạn bởi OS scheduling. Thêm isolcpus vào tham số khởi động kernel:

# Trong /etc/default/grub, thêm vào GRUB_CMDLINE_LINUX_DEFAULT:
# isolcpus=2,3,4,5 nohz_full=2,3,4,5 rcu_nocbs=2,3,4,5

# Sau update-grub và khởi động lại, xác nhận:
cat /sys/devices/system/cpu/isolated

Core 0-1 vẫn dành cho OS. Core 2+ được dành riêng cho các thread polling DPDK. Nếu không có điều này, các gián đoạn của OS scheduler gây ra đột biến độ trễ và giảm thông lượng.

NUMA Awareness quan trọng ở quy mô lớn

# Kiểm tra topology NUMA của bạn
numactl --hardware

# Luôn cấp phát mempool trên cùng NUMA node với NIC
# rte_socket_id() trả về socket của thread hiện tại
# Khớp PMD core với NUMA socket của NIC

# Kiểm tra NIC của bạn nằm trên socket nào:
cat /sys/bus/pci/devices/0000:03:00.0/numa_node

Việc vượt ranh giới NUMA với packet buffer có thể giảm thông lượng đến 30-40% trên máy chủ dual-socket. Điều này đã gây hại cho chúng tôi rất nặng trong một triển khai 25GbE — NIC nằm trên socket 0, nhưng chúng tôi lại ghim các PMD thread vào core của socket 1. Thông lượng chỉ bằng một nửa mức tối đa lý thuyết cho đến khi chúng tôi phát hiện ra.

Tinh chỉnh số lượng RSS Queue

RSS (Receive Side Scaling) phân phối các luồng đến qua nhiều RX queue. Nhiều queue hơn = nhiều PMD thread hơn = tận dụng đa lõi tốt hơn:

# Trong testpmd, kiểm tra thống kê queue theo từng queue
testpmd> show port 0 rxq 0 desc used count
testpmd> show port stats 0

# Cho môi trường production: khớp số RX queue với số core đã cô lập
# --rxq=4 --nb-cores=4 là điểm bắt đầu phổ biến cho 10GbE

Debug Packet Drops

# Kiểm tra bộ đếm drop ở cấp NIC (trước khi DPDK thấy gói tin)
dpdk-devbind.py --status

# Bên trong testpmd:
testpmd> show port xstats 0
# Tìm: rx_missed_errors, rx_no_mbuf_errors
# rx_missed_errors = NIC đã drop (mbuf pool cạn kiệt hoặc ring đầy)
# rx_no_mbuf_errors = ứng dụng xử lý quá chậm từ ring

Nếu bạn thấy rx_no_mbuf_errors, mempool của bạn quá nhỏ hoặc logic xử lý quá chậm. Hãy tăng kích thước pool trước, rồi profile hàm xử lý gói tin của bạn.

Bắt đầu với testpmd trước khi viết bất kỳ code nào

Mỗi lần tôi cài DPDK trên một máy chủ mới, testpmd là thứ đầu tiên tôi chạy. Nó phát hiện hugepage cấu hình sai, driver binding sai và vấn đề IOMMU trong vài giây — trước khi tôi đã đầu tư hàng giờ vào code tùy chỉnh. Nếu nó không hiển thị gói tin chạy qua, có nghĩa là có vấn đề phần cứng hoặc cấu hình OS cần sửa trước.

DPDK có đường cong học tập thực sự — buổi chiều đầu tiên cảm giác như đang chiến đấu với phần cứng. Nhưng khi hugepages được tinh chỉnh, CPU được cô lập, và benchmark đầu tiên của bạn cho kết quả 14Mpps trên NIC 10GbE với độ trễ trung vị 800ns, khoản đầu tư đó nhanh chóng được bù đắp. Khi đó, kernel network stack trở thành thứ bạn chỉ đọc trong các bài phân tích “tại sao chúng tôi viết lại tầng mạng”.