LAB ENGINEERING

Kiểm thử DPDK dataplane: NUMA, hugepage và packet loss

25/8/2026 · 16 phút đọc

Máy chủ hai NUMA node với NIC, CPU core, hugepage và traffic generator
Mục lục bài viết 10 phần

1. Câu hỏi kiểm thử cần trả lời 2. Topology phần cứng và điểm đo 3. Biến số phải kiểm soát 4. KPI và bằng chứng đầu ra 5. Ma trận quyết định 6. Test plan theo từng pha 7. NUMA locality, queue và burst 8. Runbook thực hành 9. Giới hạn kết luận

ĐỌC NHANH

Bài viết giúp bạn

  • Câu hỏi kiểm thử cần trả lời
  • Topology phần cứng và điểm đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Câu hỏi kiểm thử cần trả lời

#

Test phải xác định dataplane chuyển được bao nhiêu packet/bit trong điều kiện không vượt frame loss và latency budget, đồng thời chỉ ra bottleneck nằm ở NIC, PCIe, queue, memory hay CPU. Tách offered load, received load, NIC drop, software drop và application drop.

Đừng chỉ chạy 64-byte frame. Tạo IMIX hoặc frame-size matrix, nhiều flow và direction; với application forwarding, giữ rõ chức năng thực hiện như L2 forward, routing, ACL, crypto hay encapsulation.

02

Topology phần cứng và điểm đo

#

Vẽ NIC port và PCIe bus gắn với NUMA node nào, core nào chạy RX/TX/worker/control, memory channel và hugepage nằm ở đâu. Ghi BIOS, SMT, power profile, IOMMU, driver/PMD, firmware, link speed/FEC và OS kernel.

Traffic generator nối hai phía hoặc loop topology có timestamp độc lập. Thu NIC hardware counter, DPDK xstats, per-queue counter, CPU cycle, cache miss, memory bandwidth và temperature/frequency. Đồng bộ event marker khi thay tải.

Minh họa kỹ thuật: Topology phần cứng và điểm đo
Minh họa kỹ thuật: Topology phần cứng và điểm đo
03

Biến số phải kiểm soát

#

Khóa DPDK/version, PMD, EAL arguments, lcore mask, socket memory, hugepage size/count, RX/TX queue, descriptor, burst size, mbuf pool/cache và offload. Ghi RSS key/hash, flow rule và NUMA allocation.

Ở host, kiểm soát CPU governor/frequency, C-state, SMT, IRQ affinity, kernel isolation, background process và thermal state. Với traffic, nêu frame size, flow count, MAC/IP/port entropy, direction, burst/gap và ramp pattern.

04

KPI và bằng chứng đầu ra

#

KPI · Đo lường · Bằng chứng No-drop throughput · Mức cao nhất trong loss budget · TX/RX raw counters Latency/jitter · p50/p95/p99/max · Hardware timestamp Drop location · NIC/queue/app · xstats + app counters CPU efficiency · packet hoặc bit/core/s · Cycle + core utilization Headroom · Queue occupancy/burst absorption · Per-queue telemetry Stability · Drift trong soak · Time series nhiệt/frequency

Pass/fail phải nêu duration, warm-up, loss threshold và confidence/repeat count. Báo packet/s lẫn bit/s; overhead L1/L2 phải nhất quán khi so sánh.

05

Ma trận quyết định

#

Biến · Case · Câu hỏi NUMA · local vs remote core/memory · Locality ảnh hưởng bao nhiêu? Hugepage · size/count khác nhau · Allocation/TLB có ổn định? Queue · 1, N, oversubscribed · Scale tuyến tính tới đâu? Frame · 64–jumbo–IMIX · Bottleneck pps hay bandwidth? Flow · ít/nhiều entropy · RSS phân phối đều không? Burst · constant vs microburst · Queue/drop xuất hiện ở đâu? CPU · fixed vs dynamic frequency · Tail latency có drift?

Chỉ so hai case khi phần còn lại giữ nguyên. Lặp thứ tự đảo ngược để phát hiện ảnh hưởng nhiệt và cache warm-up.

06

Test plan theo từng pha

#

Pha sanity xác minh link, NUMA, queue, descriptor và counter. Pha baseline chạy từng frame size ở tải thấp. Pha search tăng offered load theo step/coarse-to-fine tới ngưỡng loss; giữ steady-state đủ lâu.

Pha scale tăng core/queue/flow; pha burst dùng burst length/gap biết trước; pha failure restart process hoặc link theo phạm vi được duyệt. Pha soak giữ tải dưới ngưỡng để tìm memory leak, frequency throttle và counter drift. Lưu EAL args, topology dump, config hash, xstats và raw generator result.

07

NUMA locality, queue và burst

#

So local/local, local/remote memory và remote core một cách có kiểm soát. Theo dõi memory bandwidth, cache miss và latency; không chỉ nhìn average CPU. Nếu queue phân phối không đều do RSS entropy, thêm flow mix trước khi kết luận scale kém.

Microburst phải có burst duration, inter-burst gap và timestamp. Đối chiếu descriptor occupancy với RX missed, no-mbuf và application drop. Tăng descriptor có thể giảm drop nhưng tăng latency/memory; quyết định phải dựa cả hai KPI.

Minh họa kiểm chứng: NUMA locality, queue và burst
Minh họa kiểm chứng: NUMA locality, queue và burst
08

Runbook thực hành

#
  • [ ] Ghi CPU/NUMA/PCIe/NIC/firmware/BIOS topology.
  • [ ] Khóa DPDK, PMD, EAL, hugepage và offload.
  • [ ] Pin core/queue/IRQ; dừng workload nền không thuộc test.
  • [ ] Warm-up và chạy baseline từng frame size.
  • [ ] Tìm no-drop throughput bằng bước tải có kiểm soát.
  • [ ] Thử local/remote memory và core placement.
  • [ ] Tăng flow/queue/core; kiểm tra RSS balance.
  • [ ] Tiêm microburst; đối chiếu xstats/drop location.
  • [ ] Chạy soak; lưu nhiệt độ, frequency và raw counters.
09

Giới hạn kết luận

#

Kết quả chỉ áp dụng cho CPU, NIC, PCIe, firmware, DPDK/PMD, EAL, frame/flow mix và topology đã thử. testpmd forwarding không đại diện đầy đủ ứng dụng có ACL, crypto hoặc state table.

Không so datasheet với lab nếu cách tính L1/L2 overhead, port direction hoặc loss threshold khác nhau. CPU utilization thấp có thể che bottleneck memory/queue; cần nhiều bằng chứng tương quan.

10

Khái niệm cần nhớ

#
  • DPDK: Bộ thư viện/userspace driver cho xử lý packet nhanh.
  • PMD: Poll Mode Driver đọc/ghi NIC bằng polling.
  • NUMA: Kiến trúc có độ trễ memory phụ thuộc socket.
  • Hugepage: Trang nhớ lớn giảm áp lực TLB và dùng cho memory pool.
  • mbuf: Buffer packet của DPDK.
  • RSS: Phân phối flow vào nhiều receive queue.
  • No-drop throughput: Tải cao nhất trong loss budget đã định nghĩa.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

DUT / SUT
Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
Steady state
Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
Pass / fail
Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật