4. 报文描述符与缓冲区管理

在 SmartNIC 的数据面上，报文从 MAC 进入、经过解析、分类、修改，最终被 DMA 写入主机内存，这一整条链路都依赖两类基础资源：描述符和缓冲区。描述符负责“说明这块数据是什么、放在哪里、该怎么处理”，缓冲区负责“真正承载报文字节”。理解这两者的结构、生命周期与分配策略，是写出高吞吐、低时延数据面程序的前提。

Packet Descriptor：报文的“身份证”

Packet descriptor 是硬件与软件之间传递报文元信息的紧凑结构。它通常不包含报文本体，而是包含指向报文的指针、长度、端口号、队列号、哈希值、校验和状态、时间戳以及各类 offload 标志。在 Marvell 这类可编程 SmartNIC 上，描述符往往由硬件解析器生成，软件可以读取甚至修改其中的字段，再决定后续处理路径。

一个典型的描述符在概念上可拆为三部分：定位信息（buffer 地址、偏移、长度）、解析结果（L2/L3/L4 类型、五元组、VLAN、隧道信息）、处理指令（是否校验和卸载、是否镜像、目标队列或目标端口）。描述符设计得越紧凑，单位时间内能处理的报文就越多，因为描述符本身也要占用 DMA 带宽和缓存行。

WQE 与 CQE：队列上的工作单元

在队列化数据面中，软件与硬件通过工作队列交互。软件向发送队列提交 WQE（Work Queue Element），描述“要发送哪块缓冲区、用什么封装、目标是谁”；硬件完成发送或接收后，向完成队列写入 CQE（Completion Queue Element），告知“哪个 WQE 已完成、状态如何”。

WQE 与 CQE 的关键区别在于方向与所有权：WQE 由软件生产、硬件消费；CQE 由硬件生产、软件消费。二者构成一个生产者—消费者环。工程上必须严格控制环的深度与批量提交/回收策略，否则会出现队列空转或 CQE 积压。例如，若发送环深度为 1024，软件一次批量提交 64 个 WQE，硬件按序完成并写回 CQE，软件再批量回收，就能显著降低 doorbell 与中断开销。

Buffer Pool 与 mbuf 式内存管理

报文缓冲区不能每次收发都临时 malloc，否则分配器锁竞争和内存碎片会直接拖垮性能。工程上普遍采用 buffer pool：启动时一次性申请大块内存，切成固定大小的 mbuf，放入空闲链表。收包时从池中取一个 mbuf 挂到描述符上，处理完成后归还池中。

mbuf 式管理的核心是“固定大小 + 引用计数 + 链式拼接”。固定大小让分配和回收都是 O(1) 的链表操作；引用计数支持一份数据被多个消费者共享（如镜像、多播）；当报文大于单个 mbuf 时，用 next 指针把多个 mbuf 串成链，避免大块连续内存分配。示例参数：mbuf 数据区 2048 字节，头部元数据 128 字节，池容量 4096，可支撑约 8MB 的报文缓存。若平均报文 512 字节，则单池可同时容纳约 4096 个在途报文。

零拷贝：让数据只搬一次

传统路径中，报文从网卡 DMA 到内核缓冲区，再拷贝到用户态，再拷贝到应用缓冲区，多次拷贝消耗大量内存带宽。零拷贝的目标是让报文数据在整条处理链中只被 DMA 搬运一次，后续各层只传递描述符或指针。

实现零拷贝通常需要三个条件：第一，缓冲区由统一的内存池管理，物理地址连续或已注册为 DMA 可访问；第二，各处理阶段传递的是描述符/指针而非数据副本；第三，需要修改报文时采用“写时复制”或预留头部空间（headroom）的方式，而不是整体复制。例如在 mbuf 中预留 128 字节 headroom，封装隧道时直接在前方写入新头部，无需搬移原有载荷。

多队列分配策略

多队列是把不同报文分散到多个队列并行处理，从而利用多核。分配策略决定“哪个报文进哪个队列”，常见有三类：

• 按流哈希：用五元组哈希取模队列数，保证同一连接始终进同一队列，避免乱序，适合有状态处理。
• 按 RSS：硬件根据 RSS 密钥和哈希函数直接计算目标队列，软件无需干预，吞吐最高。
• 按优先级/类型：控制报文、管理报文、数据报文分流到不同队列，便于差异化调度。

队列数与 CPU 核数的关系需要权衡：队列数等于工作线程数时，每核独占一个队列，缓存局部性最好；队列数过多会导致每队列深度变浅、突发吸收能力下降。示例配置：16 核系统，创建 16 个 RX 队列，每队列 1024 个描述符，RSS 哈希使用默认 Toeplitz 算法，即可在保证流有序的前提下接近线速。

关键参数速查

实际调优时，先用描述符和 CQE 的统计确认队列是否打满，再检查 buffer pool 的耗尽计数，最后根据 CPU 利用率调整队列与核的绑定关系。只有三者匹配，数据面才能稳定运行在目标速率。