📚 课程目录第1章课程导入与数据面工程全景

1. 课程导入与数据面工程全景

在开始写第一行 DPDK 或 eBPF 代码之前，我们需要先建立一张"数据面地图"：数据包从网卡进入系统，到被应用程序处理、转发或丢弃，中间究竟经过了哪些环节？DPDK 和 eBPF 各自站在哪个位置？它们解决的是同一类问题，还是互补的两类问题？只有把这张地图画清楚，后续的轮询模式驱动、内存池、无锁环形队列、XDP 挂载点、eBPF map 等具体技术才有落脚点。

什么是数据面

网络系统通常被划分为控制面、管理面和数据面。控制面负责路由计算、邻居发现、策略下发，对时延不敏感，但要求逻辑正确；管理面负责配置、监控、告警；数据面则负责对每一个到达的数据包做"逐包处理"——解析、查表、修改、转发、丢弃、计数。数据面的核心指标是吞吐量（pps 或 Gbps）、时延、时延抖动和每包处理成本，它决定了设备能不能在 10G、25G、100G 甚至 400G 线速下不丢包。

传统 Linux 内核网络栈是为通用性设计的：数据包从网卡驱动经 NAPI 轮询进入内核，穿过 netfilter、路由、邻居子系统、socket 层，再拷贝到用户态。这条路径功能完备，但每包要经历多次内存拷贝、系统调用、上下文切换和锁竞争，单核处理能力往往只有几十万到一两百万 pps。当业务要求单核处理千万级 pps 时，内核协议栈就成了瓶颈。

DPDK 与 eBPF 的定位差异

DPDK（Data Plane Development Kit）的思路是"绕过内核"：通过 UIO/VFIO 把网卡设备直接映射到用户态，配合大页内存、轮询模式驱动（PMD）、无锁环形队列（ring）、内存池（mempool）和 CPU 亲和性绑定，让应用程序在用户态直接收发数据包。它把控制权完全交给开发者，性能上限极高，代价是需要自己实现协议处理、连接管理、异常处理等一切逻辑，且通常独占 CPU 核心和网卡队列。

eBPF 的思路是"安全地进入内核"：它允许用户把经过验证的字节码程序挂载到内核的特定钩子点上，例如 XDP（eXpress Data Path，位于网卡驱动收包最早阶段）、TC（traffic control）入口/出口、socket 层、kprobe/tracepoint 等。eBPF 程序运行在内核态，无需拷贝到用户态即可完成过滤、转发、统计、重定向等操作，同时由验证器保证不会崩溃内核。XDP 在驱动层就能决定"丢弃、通过、重定向、发送"，是当前内核态高性能数据面的主力。

两者并非替代关系。DPDK 适合需要完全自定义协议栈、追求极致性能、愿意独占资源的场景，如 5G UPF、vBNG、负载均衡器、防火墙；eBPF/XDP 适合希望复用内核网络栈、按需加速特定路径、可观测性要求高的场景，如 DDoS 清洗、服务网格加速、容器网络、性能诊断。工程实践中，二者也常协同：用 XDP 做前置过滤和流量分发，把需要深度处理的流量交给 DPDK 用户态程序，或者用 eBPF 观测 DPDK 程序无法覆盖的内核路径。

协同关系与分层思路

把上图读成一条"决策链"会更实用。数据包到达网卡后，第一道关口是 XDP：如果只是简单的五元组过滤、SYN Flood 丢弃、或者把流量按哈希分发到不同 CPU 队列，XDP 在驱动层就能完成，成本极低。第二道关口是 TC eBPF：需要更复杂的策略、限速、重定向到容器 veth 时，TC 钩子更合适。第三道关口才是内核协议栈或 DPDK 用户态程序：前者适合通用 TCP/IP 业务，后者适合自研转发面。

一个典型的工程组合是：XDP 程序做 DDoS 清洗和流量分类，把"干净"流量通过 XDP_REDIRECT 送到 AF_XDP socket 或 DPDK 绑定的队列；DPDK 程序做深度包检测和转发；同时用 kprobe/tracepoint eBPF 程序采集内核侧丢包点和时延分布，用 ringbuf 上报到用户态做可视化。这样既拿到了 DPDK 的性能，又保留了 eBPF 的灵活观测能力。

学习路径建议

本课程按"先建立直觉、再动手实现、最后做性能与排障"的顺序推进。建议的学习路径是：

第一阶段（基础）：理解数据面指标、Linux 收包路径、DPDK 的 PMD/Mempool/Ring 三大件、eBPF 的程序类型与验证器机制。
第二阶段（动手）：编译并运行 DPDK 的 l2fwd/skeleton 示例，写第一个 XDP 程序并用 bpftool 加载，观察 counters map 的变化。
第三阶段（进阶）：实现一个最小转发面，对比内核栈、XDP、DPDK 三种路径在同一台机器上的 pps 与 CPU 占用。
第四阶段（工程）：做性能调优（大页、NUMA、CPU 隔离、队列绑定）、排障（丢包点定位、map 溢出、验证器报错）与协同部署。

实验环境搭建

为了让后续实验可复现，建议准备一台具备两块万兆网卡的 x86_64 服务器或虚拟机（虚拟机需支持 SR-IOV 或 virtio 多队列），操作系统使用 Ubuntu 22.04 LTS 或 CentOS Stream 9。核心依赖包括：内核 5.15 以上（XDP 与 BPF ringbuf 支持较完整）、DPDK 22.11 或 23.11 LTS、libbpf + bpftool、clang/LLVM 14 以上（用于编译 eBPF 字节码）、以及 python3 用于辅助脚本。

环境准备的关键命令如下，建议逐条执行并确认输出：

# 1. 确认内核版本与 BPF 支持
uname -r
grep CONFIG_BPF_SYSCALL /boot/config-$(uname -r)

# 2. 安装依赖（Ubuntu 示例）
sudo apt update
sudo apt install -y build-essential clang llvm libelf-dev \
  libbpf-dev bpftool linux-tools-common linux-tools-$(uname -r) \
  python3-pip meson ninja-build pkg-config libnuma-dev

# 3. 配置大页内存（DPDK 必需）
echo 1024 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
grep HugePages /proc/meminfo

# 4. 绑定网卡到 vfio-pci（DPDK 直通）
sudo modprobe vfio-pci
sudo dpkg -i dpdk_*.deb   # 或源码编译后使用 usertools/dpdk-devbind.py
sudo python3 dpdk-devbind.py --status
sudo python3 dpdk-devbind.py --bind=vfio-pci 0000:03:00.0

# 5. 验证 eBPF 工具链
bpftool version
clang --version

大页数量按实验规模调整：l2fwd 单队列通常 512 个 2MB 大页足够；若要做多队列 + 多进程，建议预留 2048 个以上。绑定网卡前务必确认该网卡不承载 SSH 管理流量，否则会断连。

如何判断环境是否就绪

可以用三个最小验证来确认环境可用。第一，运行 dpdk-testpmd 或 l2fwd，观察是否打印出网卡端口信息并能持续收发包计数；第二，用 bpftool prog load 加载一个最简单的 XDP 程序（返回 XDP_PASS），再用 bpftool net show 确认已挂载到目标网卡；第三，用 bpftool map dump 读取程序写入的计数 map，确认用户态能读到内核态数据。三者都通过，说明 DPDK 与 eBPF 两条链路都已打通，可以进入后续章节的具体实现。

需要提醒的是，DPDK 绑定网卡后该网卡对内核不可见，eBPF 的 XDP 程序也无法再挂载到已被 DPDK 接管的队列上。因此实验中要明确区分"哪块网卡给 DPDK、哪块网卡给 XDP"，或者使用同一物理网卡的不同队列配合 bifurcated driver（如 netdevsim 或支持 XDP 与 AF_XDP 共存的驱动）来观察协同行为。这个边界在后续做协同部署时会反复遇到，现在先建立清晰认知。