简介这是一份面向DPDK学习者与网络性能优化人员的《深入浅出DPDK》全书读书笔记。笔记从传统网卡中断驱动在高速网络下的性能瓶颈切入逐步梳理NAPI轮询、Netmap共享包池、用户态驱动等演进方案并深入讲解DPDK的多队列流分类、大页内存、无锁环等核心库组件以及NFV、SDN融合场景下的实际应用。资源为1个PDF文档大小约6.57MB方便移动端与PC端随时查阅目前已有3851人学习下载。除概念梳理外笔记还整理了rte_eal_init初始化流程、三层转发查表等关键实现细节可帮助读者快速建立DPDK知识框架节省通读原书时间适合网络工程师、虚拟化开发者及备赛学生作为参考。1. 为什么一本 DPDK 读书笔记值得从 PDF 开始自己整理《深入浅出DPDK》全书读书笔记.pdf拿到手以后先别急着往后翻。DPDKData Plane Development Kit解决的是服务器网卡处理能力跟不上转发需求的问题它把数据面从内核协议栈挪到用户态进程里用轮询、大页、无锁队列换来极低的收包延迟和很高的包吞吐。读书笔记这东西如果只是抄了几个 API 和命令那它还原不了这本书的价值真正有用的笔记是能把原理、命令、参数、报错串成一条可以复现的路径。下面这份整理就顺着这条路径走一遍从为什么快开始到配置环境、跑通最小转发示例最后聊聊那些没有写在书里、却一定会遇到的坑。2. DPDK 为什么快从内核中断到用户态轮询的代价账很多同学第一次接触 DPDK 是被“零拷贝”“用户态驱动”这些词吸引的。这些词单独看都对但它们不是并列关系而是一条因果链。链的起点是中断。把这条链理清楚后面看源码和调参才有方向感。2.1 中断驱动收包到底贵在哪里普通网卡收一个包完整路径大概是这样的网卡收到报文后 DMA 到内核内存驱动在中断上下文里把包拿住然后交给软中断处理协议栈一层层剥头最后把 payload 拷贝到应用进程的 socket 缓冲区应用再 read 一次才算到手。这中间有好几笔不能忽略的成本一次硬中断、一次软中断、若干次进程调度、一到两次内存拷贝。如果每秒钟来几十万个小包光是中断和上下文切换就能把一个核跑满应用还在那边等调度。DPDK 的第一刀切在中断上让网卡驱动不再因为每个包都打断 CPU而是由应用进程主动轮询网卡接收队列。轮询的代价是 CPU 占用持续接近 100%好处是收包路径完全由应用自己控制没有内核切换也没有调度抖动。量变引起质变当 CPU 一直守在接收队列旁边包到达以后只需要做一次批量读取延迟分布会非常稳定而不是一会儿快一会儿慢。想达到这个效果有两个前提必须满足。第一应用要能直接访问网卡设备的内存和寄存器这通常由 UIO 或 VFIO 机制提供用户态设备映射第二网卡 DMA 的内存必须是固定映射的普通内存页面换到磁盘会出大事所以要用大页内存提前锁在物理内存里。这两点在笔记里对应到两条命令加载用户态驱动模块、分配并挂载大页目录。很多环境问题都是这两个前提没有同时满足引起的。2.2 收一条包链路上有哪些环节被拿掉了画数据路径图的时候左边是网卡右边是应用中间横着内核协议栈。DPDK 的思路是绕开中间层让应用直接面向网卡队列。常见收包路径可以简化为四步网卡 DMA 写入内存池中的 mbuf应用调用 rte_eth_rx_burst 从接收队列取出一批 mbuf应用处理完包调用 rte_pktmbuf_free 把 mbuf 还给内存池。注意DMA 拷贝仍然存在网卡必须把数据从线上搬到内存“零拷贝”说的是内核与用户态之间没有第二次拷贝不是网卡到内存没有拷贝。这个细节搞反后面很容易误判性能瓶颈。读书笔记里我建议画三张图否则看代码很容易迷路。第一张是收包数据路径图必须标出 rx_queue、tx_queue 和内存池的位置第二张是 rte_mbuf 的内存布局头部、数据区、引用计数、池指针各占哪里第三张是 rte_ring 的出队入队状态特别是 head 和 tail 指针什么时候更新。很多读源码的挫败感来自只盯函数不看结构体这三张图恰好能把函数调用和数据结构串起来。这三张图对应的代码位置也很固定rte_eth_rx_burst、rte_pktmbuf_free、rte_ring_enqueue 和 rte_ring_dequeue。记函数时不要只抄签名要写“这个函数站在哪两个组件之间它读写的是谁”。比如 rte_eth_rx_burst 站在网卡驱动和用户代码之间它把已经到达的包从驱动接收队列搬到调用者传入的 mbuf 指针数组里。想清楚这一层再去看源码里的循环和边界判断就不会被细节淹没。2.3 用户态驱动不是万能药DPDK 的适用边界读笔记时最容易产生的误解是“只要用了 DPDK 就快”。实际上它只优化数据面收发的确定性不解决业务逻辑慢的问题。如果你的包处理里有复杂查找、加密、磁盘写入这些部分的耗时仍然会被对端观察到的总延迟包含进去。DPDK 也不会帮 TCP 连接管理提速因为它砍掉的通常是内核协议栈的 TCP/IP 处理。UDP 转发、小包过滤、负载均衡这类场景收益最大而需要完整 TCP 状态机的应用要么自己实现 TCP 栈要么继续用内核协议栈复杂度会明显上升。所以整理 DPDK 读书笔记时最好在开头先写一段“这本书在替什么问题给出路”。我看到很多笔记一上来就是大页配置和收包代码却没有写“什么时候不要用 DPDK”。这个边界没划清后面照搬到业务里很容易翻车。我一般这样判断如果业务里每秒小包数量不超过十万并且延迟要求不苛刻内核协议栈配合网卡多队列也能应付如果包量到了每秒百万级业务逻辑又简单才值得上 DPDK。这个量级判断不是书里的原话但笔记里值得补上。另一个容易被忽略的点是 NUMA。DPDK 网卡和内存的亲和性决定跨节点带宽插错节点会让性能下降一截。很多人把这当作“玄学”其实大多数情况是网卡挂在 node 1而大页内存和 CPU 都分配在 node 0。3. 把 DPDK 跑起来Hugepages 配置、网卡绑定与最小转发示例读书笔记的中间部分是从“看得懂”到“跑得起来”的分界线。不要急着写正式业务代码先准备环境。环境不对后面每一句报错都会让你怀疑自己的代码而实际上问题往往在系统和驱动层。3.1 大页内存先看现状再分配收包时网卡要把数据 DMA 到内存这块内存需要连续和固定映射否则驱动要为零散页面付出额外成本。DPDK 的做法是使用大页内存常见页大小是 2MB 和 1GB。笔记里要记一套固定动作先看当前系统大页是多少再决定要不要调。# 查看系统当前大页大小和数量 grep -E Hugepagesize|HugePages_Total|HugePages_Free /proc/meminfo # 给 2MB 大页分配 1024 个约 2GB echo 1024 /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # 把大页挂载到专门目录供 DPDK 访问 mkdir -p /mnt/huge mount -t hugetlbfs -o pagesize2M nodev /mnt/huge第一行 grep 是在改配置之前必须做的现状检查。HugePages_Total 表示已经分配的大页总数HugePages_Free 是剩余可用数量。如果 Total 已经是 0后面的 echo 才会真正生效。第二行是临时分配重启后会丢生产环境建议把 vm.nr_hugepages 写进 /etc/sysctl.conf。第三行挂载目录也会随重启失效需要持久化就写进 /etc/fstab。参数说明pagesize2M 必须与 /proc/meminfo 里看到的 Hugepagesize 一致。如果机器内存比较大或者网卡队列数量多、mbuf 池开得大建议考虑 1GB 大页。1GB 大页的分配方式不太一样需要在内核启动参数里预留比如在 grub 命令行里加 hugepagesz1G hugepages4而不是运行时直接 echo。笔记里我通常会写一句提醒“先搞清楚跑测试的机器有没有空闲连续内存再决定页大小。” 这个顺序反了后面经常会发现大页根本申请不下来。3.2 网卡绑定从内核驱动切到用户态驱动DPDK 不能直接接管一块已经被内核驱动绑定的网卡必须把网卡的 PCI 设备重新绑定到用户态驱动。常见用户态驱动有 igb_uio 和 vfio-pci。开发环境最省事的是 igb_uio但要自己编译加载模块生产环境一般用 vfio-pci它走系统 VFIO 机制还能配合 IOMMU 做设备隔离。第一次复现建议先不用 vfio-pci避免把 IOMMU 配置问题混进来。# 查看当前网卡 PCI 地址和驱动归属 dpdk-devbind.py --status # 加载用户态驱动模块 modprobe igb_uio # 把 0000:03:00.0 这个网卡绑定到 igb_uio dpdk-devbind.py --bindigb_uio 0000:03:00.0 # 再次确认驱动已经切换 dpdk-devbind.py --statusdpdk-devbind.py 是 DPDK 自带的工具路径一般在 DPDK 编译目录的 usertools 下。先执行 --status 看设备列表找到你要绑定的网卡对应的 PCI 地址。千万不要凭接口名 eth0 去猜因为绑定后在内核里就没有 eth0 了。绑定时要保证没有其他进程占用这块网卡否则会报 Device or resource busy。参数说明--bind 后面跟的是用户态驱动名不是网卡接口名。PCI 地址格式是 domain:bus:device.function写全四位冒号分隔。绑定成功后 ifconfig -a 里看不到这个接口是正常的说明它已经从内核手中交出来了。如果主机上有多个网口只绑一个口测试另一个口保留给 SSH 和管理用途这是避免远程把自己关在门外的血泪经验。3.3 testpmd 最小启动跑通第一个收包循环环境准备好以后不要立刻写 C 代码先用 testpmd 验证环境。testpmd 是 DPDK 自带的命令行交互工具也是新手最好的调试入口。# 用两个核启动 testpmd进入交互模式 dpdk-testpmd -l 0-1 -n 2 -- -i # 在交互模式里启动端口收包 testpmd start testpmd show port stats all第一次启动-l 0-1 表示让 DPDK 使用核 0 和核 1-n 2 表示每个 socket 两个内存通道。这两个参数必须和机器实际拓扑一致如果 CPU 有两个 NUMA 节点-n 通常填 2 或 4。填错最直接的后果是启动阶段报内存通道相关错误。-- -i 表示进入交互模式后面还可以追加端口数、队列数、mbuf 池大小等参数但最小验证用默认值就够了。testpmd start 之后如果网卡对端有流量打过来show port stats all 里的 RX packets 会增长。这一步跑通说明大页、驱动绑定、内存通道、设备权限这些基础项都是对的。很多人把这一步省略直接跑自己的转发程序结果环境问题与应用问题混在一起非常难排查。我一般会先用 testpmd 打几分钟原始流量确认没有丢包趋势再往下做。这也是我做环境问题最常用的“后悔药”。4. 核心组件阅读顺序mbuf、ring、lcore 与收包路径整理读书笔记时如果按书从前到后记很快会被 API 淹没。我更推荐的阅读顺序是先看数据从网卡出来以后进了哪个结构体再看这个结构体怎么在核与核之间传递最后才看线程怎么跑。顺着这个顺序读入口和出口永远清晰。4.1 rte_mbuf包描述符不是一块普通堆内存rte_mbuf 是 DPDK 收发数据的基本单元。它里面存的是包在内存池里的偏移、数据长度、收包端口、队列、时间戳、引用计数等信息包的实际字节数据存在 struct rte_mbuf 后面的数据区里。笔记里要记的不是字段表而是“为什么连续存放”网卡 DMA 需要按地址连续访问多个 mbuf 从内存池分配时物理地址尽可能贴近cache 预取才有效。一个典型的分配动作是调用 rte_pktmbuf_alloc(pool)释放动作是 rte_pktmbuf_free(mbuf)。初始化时决定每个 mbuf 最大能装多少字节、池里总共有多少个 mbuf。这两个数字直接影响吞吐和大包场景的稳定性。池开小了突发流量一来就分不到 mbuf收包引擎会直接丢包开大了内存占用又高尤其在使用 1GB 大页时要精打细算。读书笔记里最好记一个估算公式总 mbuf 数 队列深度 × 队列数 socket 缓冲余量再乘以 1.2 左右的安全系数。这里有一个经常误用的点rte_pktmbuf_free 并不是马上把内存归还操作系统而是还给那个内存池。内存池本身来自大页内存所以高频分配释放的成本远低于普通 malloc/free。如果你的业务代码里出现“每次收包都 malloc 一次”说明还没有理解 DPDK 的内存池模型性能大概率上不去。4.2 rte_ring无锁队列的四个角色rte_ring 是 DPDK 多核之间传递 mbuf 指针的无锁环形队列。它支持四种模式单生产者单消费者SP/SC、单生产者多消费者SP/MC、多生产者单消费者MP/SC、多生产者多消费者MP/MC。性能上 SP/SC 最快因为它只有一个读指针和一个写指针在动几乎不需要原子操作MP/MC 为了保证并发安全需要使用 cmpxchg 之类的操作成本明显更高。我在笔记里画过一张状态表按“生产者个数 × 消费者个数”分成四个格子每个格子标注应不应该加锁、适合什么场景。比如收包线程经过一个中间队列把包交给工作线程如果只有一个收包线程、一个工作线程就用 SP/SC如果多个收包线程同时往一个队列里写就必须 MP/MC。选择错误的表现也很直接同样是转发吞吐掉一截或者偶发丢包。使用 rte_ring 时要特别注意容量必须是 2 的幂次。rte_ring_create 参数里的 num 如果不是 2 的幂函数会返回 NULL这个限制很容易在初始化阶段翻车。另一个坑是 enqueue 和 dequeue 都返回实际操作数量调用时必须判断返回值是否等于期望数量不能想当然地认为一次一定成功。环满了就丢包这是设计上允许的但你要知道它是什么时候满的否则流量模型一变就莫名其妙丢包。4.3 收包线程从单包处理到批量收发的习惯一个最小的收包循环代码上可以写成下面这样。注意看这里没有网卡初始化、没有内存池创建只突出最核心的循环结构。#define BURST_SIZE 32 struct rte_mbuf *bufs[BURST_SIZE]; for (;;) { uint16_t nb_rx; uint16_t i; nb_rx rte_eth_rx_burst(port_id, queue_id, bufs, BURST_SIZE); if (nb_rx 0) { continue; } for (i 0; i nb_rx; i) { process_packet(bufs[i]); rte_pktmbuf_free(bufs[i]); } }这个循环的核心不是 for 里的代码而是 rte_eth_rx_burst 的“批量”语义。它一次不是只取一个包而是尽量从接收队列里取到最多 BURST_SIZE 个包。CPU 连续读多个 mbuf 时cache 预取能显著降低每个包的指令成本。BURST_SIZE 通常取 32、64 或 128不是越大越好。取太大时接收队列可能长时间凑不满延迟反而变高取太小批量收益又吃不到。普通测试从 32 起步比较稳。我在笔记里会特别标一个容易忽略的限制同一个 mbuf 不能被两个核同时处理。如果收包线程和工作线程是同一个 CPU直接在这个循环里处理没有问题如果希望收包线程只负责收工作线程负责处理就必须经过 rte_ring 传 mbuf 指针而不是把同一个指针交给两个核。记住mbuf 的所有权是“单线程”的谁最后释放谁负责把指针彻底还给内存池。所有权混乱是 DPDK 程序最常见的黑匣子 bug。lcore 绑定也在这里说。lcore 是 DPDK 对 CPU 核的抽象rte_eal_remote_launch 可以把一个函数绑定到指定逻辑核执行。收包线程不要和主线程挤在同一个核。testpmd 用 -l 0-1 指定两个核一个做主线程一个做数据线程。自己写多核程序时用 rte_get_lcore_id 在子线程里确认当前核。绑核没做对调度器会频繁迁移线程污染 cache表现就是延迟时好时坏、吞吐忽高忽低。5. DPDK 排障与调优我在笔记里反复划线的 5 个坑环境层面和代码层面的问题通常混在一起。当你不确定问题在哪时先回到 testpmd再回到最小收包循环。以下五个坑是我在整理笔记时遇到最多也是最容易反复翻车的地方。5.1 网卡绑定以后testpmd 看不到端口现象dpdk-devbind.py --status 显示网卡已经绑到 igb_uio但 testpmd 启动后没有任何端口出现。原因最常见的是网卡原来对应的内核驱动模块并没有完全卸载比如 ixgbe、i40e 还占着设备或者是绑定前没确认 PCI 地址把同主机的另一个网口绑错了。还有可能是网卡型号比较特殊当前 PMD 不支持。解决先执行 modprobe -r 卸载对应的内核驱动再重新绑定。然后执行 dpdk-devbind.py --status确认 driver 列里只有 igb_uio 或 vfio-pci。如果确认型号不在支持列表里只能换网卡或换驱动。另外用 lspci -nn 看一下设备 ID和官方 PMD 列表对照能快速排除支持性问题。5.2 大页配置成功程序仍然报内存不足现象/proc/meminfo 里 HugePages_Total 足够挂载也成功但 DPDK 初始化时 EAL 报 Cannot get hugepage。原因大页虽然分配了但 DPDK 进程没有权限访问 /mnt/huge或者挂载目录的 pagesize 与系统大页不匹配。还有一个隐蔽场景想用 1GB 大页但只在运行时写 nr_hugepages没有改内核启动参数导致预留没有真正生效。解决确认挂载参数里的 pagesize 和 /proc/meminfo 的 Hugepagesize 完全一致用 mount 命令查看实际挂载目录。权限不够时先切到 root 跑一次确认路径和权限没问题再切回普通用户。1GB 大页要检查内核启动参数中是否预留了 hugepagesz1G hugepagesN而不是只依赖 sysctl。5.3 吞吐上不去CPU 占用反而很高现象testpmd 或自写程序转发速率只有几百 Mbps但 CPU 已经 100%甚至绑核之后仍感觉不到提升。原因最常见是收包线程并没有真正绑定到独立核上线程被调度器到处迁移cache 命中率下降另一个原因是 BURST_SIZE 设得太小每次都只从网卡取到一两个包批量收发的收益没吃到。解决用 rte_eal_remote_launch 把收包函数绑定到指定 lcore并确认线程的 CPU affinity。随后把 BURST_SIZE 至少调到 32。可以在启动参数里加 -l 指定核列表。如果你发现 CPU 占用 100% 但吞吐低先用 testpmd 的转发模式跑一遍如果 testpmd 也低问题就在环境层比如 NUMA 插槽、驱动、大页配置而不是你的转发逻辑。5.4 配置了多队列流量还是压在一个核上现象网卡和程序都配置了 4 个接收队列但查看各核 CPU 使用率只有第一个核在跑。原因多队列依赖网卡的 RSS 哈希。如果对端流量源 IP、目标 IP、端口都固定哈希结果可能始终落在同一个队列。另一个原因是网卡队列数设得太少或者 RSS 配置被驱动默认关闭。很多虚拟网卡设备对 RSS 支持有限也会出现这个问题。解决先确认网卡和 PMD 支持 RSS用 ethtool -l 查看最大队列数。然后在 testpmd 启动时设置 --rxq4 --txq4再打多变源流量。如果源和目的都固定哈希值本身是不变的这属于流量模型问题可以改 hash key 或者做逐队列分流但不要指望 RSS 能帮你分散固定五元组。这个坑在线下测试最容易忽视因为压测仪常常只发一条五元组。5.5 内存池耗尽收包直接失败现象程序运行几分钟后收到包数量明显下降日志出现 Pool allocation failed 或 mbuf 分配失败。原因最常见是处理路径上忘记调用 rte_pktmbuf_free导致 mbuf 有借无还另一个原因是 mbuf 被 clone 之后引用计数没有正确递减还有一个是池大小按平均包速算没有考虑突发。解决在每一条处理分支上严格保证“分配一次最终释放一次”。用 rte_pktmbuf_refcnt_update 检查引用计数如果计数不为 1说明还有别的使用者。调大 rte_pktmbuf_pool_create 的 pool_size 参数可以缓解突发但不能掩盖泄漏。最笨也最有效的检查是在循环里统计 alloc 和 free 的次数长时间跑完后两者应该保持相等。如果不等逐分支查哪里 return 了没有释放。6. 从读书笔记到落地一张自检清单和下一步验证整理完一份网卡驱动相关的技术笔记最难的是确认自己是不是真的读懂了。下面这张自检清单我贴在笔记最后每次要依赖 DPDK 做方案时先花十分钟自问一轮。6.1 笔记读没读透十个自问题问题如果答不上来说明什么为什么用大页不用大页的后果是什么内存模型还没吃透igb_uio 和 vfio-pci 的差别是什么设备绑定部分没细读rte_eth_rx_burst 的返回值表示什么收发 API 理解不够为什么 mbuf 要放在内存池而不是 malloc结构体章节没消化ring 容量为什么必须是 2 的幂无锁队列边界条件没看多消费者模式的原子操作代价有多大性能调优会踩坑收包线程不绑核会怎样理解不了 CPU 抖动池大小怎么估算才安全线上会突然丢包RSS 哈希对固定五元组是否有效多队列测试会翻车什么时候不应该用 DPDK还没掌握适用边界这张表的作用不是考试而是定位。哪一条含糊就回到对应章节补笔记而不是重新翻整本书。我自己的习惯是每隔一段时间随机抽一条心里默答一遍答不上来就说明这段时间光写代码没复习原理。6.2 下一步先做一个带统计的收包工具不要一上来写完整转发程序先做一个带计数和丢包统计的收包循环。在收包函数里用两个 uint64 变量统计总包数和丢包数先跑 30 秒用压测工具打固定流。如果丢包率为 0再逐步加大突发流量和包速率。这里没有复杂算法关键是先拿到一个能复现的基线。基线稳定以后再尝试加 rte_ring、多队列、绑核这些优化。如果一定要我给一个落地顺序我会这样排先 testpmd 验证环境再写单核收包统计然后加 ring 做线程间传递最后加多队列和 RSS。每走一步都保留一份能跑的代码和一个能对比的数字。这样某一个环节性能不对马上能看出是哪一步引入的。一句话收尾DPDK 程序的性能不是靠某个函数调出来的而是靠你始终知道“网卡数据到了哪一层、谁正在持有 mbuf、谁负责释放”。我的习惯是在每段代码开头写注释标明当前持有 mbuf 的生命周期这样不用每次都翻笔记回忆。整理《深入浅出DPDK》全书读书笔记.pdf最有价值的不是最后生成一个 PDF 文件而是在整理过程中把每个组件之间的所有权关系写清楚。遇到性能问题时按“内核绑定、大页、NUMA、队列、内存池”这个顺序排查能解决大多数情况。希望这一套思路对你整理自己的笔记也有帮助。本文还有配套的精品资源点击获取