4、Pipeline 设计哲学：从硬件交换机到软件流水线，OVS 的灵感来源。

聊到 OVS 的 Pipeline，很多人第一反应就是“查表、跳转、再查表”。

没错，这是它的表象。但它的灵魂，其实是从硬件交换机那里“偷师”来的。

我最早接触网络的时候，用的还是 Cisco 的 Catalyst 系列。那时候我就好奇：一台硬件交换机，凭什么能线速转发？后来拆开看了，里面全是 ASIC 芯片，逻辑是死的，但速度是极快的。而 OVS 呢？它跑在通用 CPU 上，凭什么也能玩出“流水线”的花样？

说白了，OVS 的 Pipeline 设计哲学，就是一场“软件向硬件致敬”的模仿秀。

4.1 硬件交换机的“硬”逻辑

硬件交换机内部，通常有一张固定的流水线。

比如，一个典型的硬件 Pipeline 可能是这样的：

• 端口入方向解析
• VLAN 处理
• MAC 学习
• 路由查找
• ACL 过滤
• 出方向封装

每一步都是固定的，芯片里写死了。你没法在 VLAN 处理之前先做 ACL，也没法在路由查找之后再做 MAC 学习。硬件设计者认为这个顺序是最优的，你就得按这个来。

嗯，这里要注意：硬件交换机的优势在于确定性。每个包走完这条流水线，延迟是固定的，吞吐是线速的。但代价是什么？灵活性差。你想加一个新功能？对不起，得换芯片。

4.2 软件流水线的“软”优势

OVS 的灵感，恰恰来自于对这种“刚性”的反叛。

我记得在 2013 年左右，我参与过一个数据中心项目。客户要求：某些流量要先做深度包检测，再做转发；而普通流量直接转发就行。硬件交换机做不到，因为它的流水线是固定的。但 OVS 可以。

为什么？因为 OVS 的 Pipeline 是“软”的。

它把硬件里的固定步骤，拆成了一个个独立的“表”。每个表只做一件事：匹配某个字段，执行某个动作。然后，你可以自由地组合这些表。你想先做 ACL 再做路由？没问题。你想在路由之后再做一次 VLAN 重写？也可以。

说白了，OVS 把硬件里那条“单行道”，变成了一个“立交桥”。你可以在不同的表之间跳来跳去，甚至可以根据包的内容决定下一步去哪。

4.3 从“固定流水线”到“可编程流水线”

硬件交换机的流水线，是设计者替你决定的。

OVS 的流水线，是开发者自己定义的。

这种转变，其实跟编程语言的演进很像。早期是汇编，指令是固定的；后来有了高级语言，你可以自己组合逻辑。OVS 的 Pipeline 就是网络领域的“高级语言”。

我们来看一个简单的对比：

特性	硬件交换机 Pipeline	OVS 软件 Pipeline
灵活性	低，固定顺序	高，可自定义
性能	极高，线速转发	受 CPU 限制
更新成本	高，需更换硬件	低，修改流表即可
调试难度	低，行为确定	高，需跟踪流表

你想想看，硬件交换机就像一条高速公路，车道固定，出口固定。而 OVS 的 Pipeline 更像是一个城市路网，你可以随时修路、封路、改道。代价就是，你得自己当交警。

4.4 OVS 的“多表”设计：一种折中

OVS 并没有完全抛弃硬件的思路。它借鉴了“多级流水线”的概念，但做了一层抽象。

在 OVS 里，每个表都有一个编号（Table 0, Table 1, ...）。包从 Table 0 开始，匹配规则，执行动作。动作里可以包含“跳转到 Table X”，这样就形成了流水线。

我个人习惯把 Table 0 叫做“入口表”，把最后一个表叫做“出口表”。中间的表，你可以随意安排。比如：

# 一个简单的 OVS Pipeline 示例
# Table 0: 入口分类
table=0, in_port=1, actions=resubmit(,10)
table=0, in_port=2, actions=resubmit(,20)

# Table 10: VLAN 处理
table=10, vlan_vid=100, actions=resubmit(,30)
table=10, vlan_vid=200, actions=resubmit(,40)

# Table 30: 路由查找
table=30, ip_dst=10.0.0.0/8, actions=mod_dl_dst(00:11:22:33:44:55), output:3

这段代码里，包从 Table 0 进来，根据入端口跳到不同的处理表。每个表只关心自己的事。这就是 Pipeline 的精髓：分而治之。

4.5 为什么 OVS 选择了“多表”而不是“单表”？

你可能会问：既然 OVS 是软件，为什么不用一个巨大的表，匹配所有字段，直接决定动作？

原因有两个。

第一，可读性。 一个包含几百个字段的匹配规则，写出来你自己都看不懂。而多表可以把逻辑拆成小块，每个块只匹配几个字段。比如，Table 10 只关心 VLAN，Table 20 只关心 IP。这样，规则变得清晰易懂。

第二，性能。 虽然 OVS 是软件，但它也要考虑查找效率。一个巨大的表，查找复杂度是 O(N)。而拆成多个小表，每个表的查找复杂度可以降到 O(log N) 甚至 O(1)。你想想看，如果每个包都要遍历几百条规则，CPU 早就烧了。

说白了，多表设计是一种“空间换时间”的妥协。它牺牲了一点灵活性（你必须按顺序跳转），换来了可维护性和性能。

4.6 硬件与软件的“双向奔赴”

有意思的是，最近几年，硬件交换机也开始学 OVS 了。

比如，P4 语言的出现，让硬件交换机也能实现“可编程流水线”。你可以用 P4 定义自己的表、自己的匹配字段、自己的动作。这其实就是把 OVS 的“软”思想，塞进了硬件的“硬”壳里。

反过来，OVS 也在向硬件学习。比如，它引入了“缓存”机制，把热门的流表项缓存到内核模块里，减少用户态和内核态的切换。这其实就是硬件里“TCAM”的软件实现。

所以，不要觉得软件和硬件是对立的。它们其实是互相借鉴、互相成就的。OVS 的 Pipeline 设计哲学，本质上就是一场“软硬融合”的探索。

嗯，这一章就聊到这里。下一章，我们会深入 OVS 的流表结构，看看那些“表”到底是怎么组织起来的。