第一章：数据平面基础
各位同学好，我是你们的DPU架构课讲师。今天咱们聊聊数据平面——这个DPU里最核心、也最容易被忽视的部分。
说实话，我见过不少刚入行的工程师，一上来就扎进控制平面的代码里，觉得那才是“智能”所在。结果呢？数据平面跑不起来，整个系统就是个摆设。我自己在早期做NFV项目时就吃过这个亏，后来才明白：数据平面才是DPU的命根子。
1.1 数据平面 vs 控制平面：到底差在哪？
先问个问题：你拆开一台交换机，里面有两套“大脑”，你猜它们分别管什么？
控制平面，说白了就是做决策的。它运行路由协议（比如OSPF、BGP），维护转发表，处理ARP请求。它不关心每个包怎么走，它只关心“路该怎么修”。
数据平面，就是干活的。它拿到一个包，查表、改头、转发——一气呵成。它不思考，只执行。你想想看，如果每个包都要等控制平面算一遍，那网络延迟得高到什么程度？
核心区别一句话：控制平面决定“做什么”，数据平面决定“怎么做”。
我在一个数据中心项目里遇到过这样的场景：控制平面跑得好好的，路由表也更新了，但数据平面就是丢包。查了半天，原来是转发表项没同步到硬件。嗯，这就是典型的“脑子懂了，手没跟上”。
两者的关键差异，我列个表给你看：
| 维度 | 控制平面 | 数据平面 |
|---|---|---|
| 处理对象 | 路由协议、管理报文 | 数据包、流 |
| 处理频率 | 毫秒级甚至秒级 | 纳秒级 |
| 实现方式 | 通用CPU、软件 | 硬件流水线、ASIC、FPGA |
| 性能要求 | 中等 | 极高（线速） |
| 典型代码 | C/Python，跑在Linux上 | P4、C（硬件描述）、eBPF |
1.2 数据平面的三大核心功能
数据平面到底干哪些活？我把它拆成三块：包处理、转发、过滤。这三件事，你想想看，是不是所有网络设备都在做？
1.2.1 包处理（Packet Processing）
包处理是基础中的基础。一个包从网口进来，你得先把它认出来：
- 解析（Parsing）：拆开以太网头、IP头、TCP/UDP头，提取关键字段。我在做智能网卡时，发现很多团队在解析上栽跟头——比如VXLAN封装没处理好，导致隧道包全丢了。
- 查表（Lookup）：用五元组（源IP、目的IP、源端口、目的端口、协议）去匹配规则表。这里有个坑：表项多了，查表速度会掉。我曾经用哈希表优化过，效果不错。
- 修改（Modification）：改MAC地址、TTL减1、NAT转换IP。注意，改完要重新计算校验和，不然对端会丢包。
我的经验：包处理流水线里，解析阶段最容易被忽略。很多新手只关注转发逻辑，结果解析器写错了，后面全白干。建议你先用Wireshark抓几个典型包，对着协议规范一行一行写解析代码。
1.2.2 转发（Forwarding）
转发就是“把包送到该去的地方”。听起来简单，但实现起来门道很多：
- 直通转发（Cut-through）：收到包开头就转发，延迟低，但可能转发坏包。我在一个金融交易系统里用过，延迟能压到几百纳秒。
- 存储转发（Store-and-forward）：收完整个包再转发，保证完整性，但延迟高。适合对可靠性要求高的场景。
- 负载均衡：多路径转发，常用ECMP（等价多路径）。注意哈希冲突会导致流量不均，我建议用一致性哈希。
你可能会问：DPU里的转发和普通交换机有什么区别？区别大了。DPU的转发是可编程的，你可以自定义转发逻辑，而不是死板地查MAC表或IP路由表。
1.2.3 过滤（Filtering）
过滤就是“不该放行的，坚决不放”。这是安全的第一道防线：
- ACL（访问控制列表）：基于IP、端口、协议做黑白名单。我在云数据中心做过一个项目，ACL规则有上万条，硬件流水线根本装不下。后来用TCAM（三态内容寻址存储器）才搞定。
- 状态检测：跟踪连接状态，只允许合法的TCP连接通过。这个比静态ACL聪明，但消耗资源也多。
- 速率限制：防止某个流占满带宽。我曾经用令牌桶算法实现过，效果很稳。
注意：过滤规则别写得太复杂。规则越多，查表越慢。我见过有人写了5000条ACL，结果吞吐量直接腰斩。记住：数据平面追求的是“快”，不是“全”。
1.3 数据平面的性能指标
做数据平面编程，你得时刻盯着三个数字：吞吐量、延迟、线速。这三个指标，说白了就是“能跑多快、等多久、能不能跑满”。
1.3.1 吞吐量（Throughput）
吞吐量就是单位时间内能处理多少数据。常用单位是bps（比特每秒）或pps（包每秒）。
举个例子：一个100Gbps的端口，如果每个包是64字节（以太网最小包），那理论最大包率是：
100Gbps / (64字节 × 8比特/字节) ≈ 1.488 Mpps注意，这是理论值。实际能跑到多少，取决于你的数据平面代码效率。我在一个项目中，用P4写的流水线能跑到1.4 Mpps，但换成C语言写的软件转发，只能到800 Kpps。差距就在这里。
1.3.2 延迟（Latency）
延迟就是包从进来到出去的时间。单位通常是微秒（μs）甚至纳秒（ns）。
延迟分两种：
- 直通延迟：从收到包开头到发出包开头的时间。DPU里一般能做到几百纳秒。
- 存储转发延迟：从收到整个包到发出整个包的时间。取决于包长，64字节包大概几微秒。
我做过一个对比测试：同样的转发逻辑，用硬件流水线延迟是200ns，用软件模拟是5μs。差了25倍！所以，对延迟敏感的场景（比如高频交易），必须用硬件数据平面。
1.3.3 线速（Line Rate）
线速，就是“跑满端口带宽”。这是数据平面的终极目标。你想想看，一个100G端口，如果只能跑50G，那另一半带宽就浪费了。
实现线速的关键在于：
- 流水线深度：每个时钟周期处理一个包，不能有气泡。
- 内存带宽：查表、改包都要访存，内存带宽不够就会卡住。
- 无锁设计：多线程访问共享资源时，锁会拖慢速度。我建议用无锁队列或硬件原子操作。
线速的残酷现实：很多号称“线速”的设备，其实只在特定包长下才能跑满。64字节小包是最难处理的，因为包率最高。如果你看到设备标称“线速”，记得问一句：“64字节包能跑满吗？”
1.4 知识体系总览
下面这张图，是我自己画的数据平面知识框架。你可以把它当成一张地图，后面每节课都会回到这张图上来。
这张图里，三大功能（包处理、转发、过滤）是数据平面的“骨架”，三大指标（吞吐量、延迟、线速）是衡量骨架是否强壮的“标尺”。后面我们会逐一深入每个模块。
1.5 避坑指南
最后，分享几个我踩过的坑，希望能帮你少走弯路：
- 别迷信“线速”：很多芯片标称线速，但实际跑小包时性能会掉。我建议你拿到芯片后，先用64字节包做压力测试。
- 控制平面别干扰数据平面：我曾经把路由更新和包转发放在同一个线程里，结果路由一更新，转发就卡顿。后来用独立线程+无锁队列才解决。
- 查表算法要选对：规则少用线性查找，规则多用哈希或TCAM。我见过有人用二叉树查100万条规则，延迟直接飙到毫秒级。
- 别忘了校验和：改包后不重新计算校验和，对端会默默丢包。这个坑我至少踩过三次。
我的建议：刚开始学数据平面编程，别急着上硬件。先用软件模拟（比如P4软件交换机、eBPF程序）跑通流程，理解每个环节的耗时。等逻辑成熟了，再移植到硬件上。这样调试成本低得多。
好了，第一章就到这里。数据平面是DPU的“肌肉”，没有它，再聪明的控制平面也只是纸上谈兵。下一章，我们会深入包处理的第一个环节——解析器，看看一个包从网口进来后，到底经历了什么。
公众号:蓝海资料掘金营，微信deep3321