简介：本资源是一份面向SDN初学者与网络开发者的Open vSwitch源码深度解析笔记，聚焦OVS核心机制与OpenFlow协议实现原理。内容系统梳理了OVS网络架构（ovs-vswitchd、ovsdb-server等组件协同关系）、内部模块分层（ofproto抽象层、ofproto-dpif实现、netdev设备抽象）及关键代码路径，尤其深入剖析datapath内核模块的初始化流程、收包处理链路（netdev_frame_hook→ovs_dp_process_packet）、流表哈希桶结构与创建逻辑（alloc_buckets、dp_flow_genl_ops），辅以清晰的数据流向图示与关键函数调用分析。资源为单文件PDF，大小1012KB，内容覆盖2.3.90版本源码，适合作为阅读OVS源码的入门指南与调试参考。目前已有977人学习下载，笔记结构完整、术语准确、注释详实，能有效帮助读者建立OVS用户态与内核态协同工作的整体认知，并快速定位关键模块源码位置与执行逻辑。

1. 别被“源码阅读笔记”吓住：它其实是一张 OVS 的「地铁线路图」，专治看不懂虚拟交换机的焦虑

你刚点开这份《Openvswitch源码阅读笔记.pdf》，看到满屏的ovs_dp_process_packet()、ofproto_dpif_class、sw_flow_key……第一反应是不是：这哪是笔记？这是天书！
别急——这恰恰说明你不是一个人。我第一次打开它时，也盯着第3页那个“datapath 流表哈希桶”的 flex_array 结构图发了15分钟呆，心想：“我连 OVS 是干啥的都没整明白，现在就要看内核模块怎么分页存流表？”

其实，这份笔记根本不是让你从头逐行背代码的“考试大纲”，而是一份给新手画的 OVS 运行地图：它不讲所有函数怎么写，但清楚标出了——数据包从网卡进来，经过哪几道门（vport → key 提取 → 流表匹配 → action 执行），哪扇门走不通会拐去用户态（upcall），哪条路是控制器远程按下的开关（OpenFlow flow_mod）。它把一个庞大、分层、横跨内核/用户态的虚拟交换系统，拆成了你能摸得着的“入口→中转站→出口”链条。

适合谁？就是你现在这个状态的人：听说过 SDN、OpenFlow、OVS，知道它们和“云网络”“虚拟机互通”有关，但一查资料就掉进术语坑里——“ofproto 是什么？”“dpif 和 netdev 有啥区别？”“为什么流表要搞 hash 桶还带 mask cache？”……这份笔记，就是专门帮你把脚从坑里拔出来，踩在第一个可理解的台阶上。它不承诺让你三天写出 patch，但能保证你读完第5页，再看到ovs-ofctl add-flow命令时，脑子里浮现的不再是黑盒子，而是一段真实跑在内存里的逻辑：哦，原来这条命令，最终是调到了ovs_flow_cmd_new()，往内核datapath的哈希桶里塞了一个新sw_flow结构体。

这就是它的价值：把玄学变常识，把黑匣子变透明管道。接下来，我们就按这张地图，从最外层的“OVS 是什么”开始，一层层剥开，直到亲手跑通第一个流表匹配实验。

2. 先搞懂一个概念：OVS 不是“软件交换机”，而是 SDN 架构里那个「听指挥的执行员」

很多新手入门第一步就卡住了：为什么非得学 OVS？Docker 自带 bridge 不也能连容器吗？Kubernetes 的 CNI 插件不也管网络吗？这里必须先划清一条线——OVS 的核心身份，不是“多了一个交换功能”，而是SDN（软件定义网络）落地的关键执行层。它存在的唯一目的，就是把远端控制器（Controller）发来的抽象策略，变成 Linux 内核里真实转发数据包的动作。我们用一个生活化类比来破冰：

想象一座智能大厦的消防系统。传统网络就像每层楼自己装独立烟雾报警器：A 层起火，A 层警报响，B 层完全不知情，更别说联动喷淋或疏散广播。而 SDN 就是给整栋楼装了一个中央消防控制室。OVS，就是安装在每一层电梯口、走廊尽头、机房门口的那些“智能消防阀”。它本身不决定“哪里起火该关哪扇门”，但它绝对服从控制室的指令：控制室说“A 区通道关闭、B 区喷淋启动”，OVS 就立刻执行；控制室说“临时加一条应急逃生路径”，OVS 就马上在流表里加一条新规则。没有 OVS，控制室的指令就是一张废纸；没有控制室，OVS 就是一堆不会思考的阀门，只能按出厂设置傻转。

所以，OVS 的本质，是OpenFlow 协议的忠实实现者。OpenFlow 就是控制室和阀门之间的“消防指令语言”。它定义了：

• 怎么描述一个数据包的特征（Match 字段：源IP、目的端口、VLAN ID…就像描述“起火点位置+火势类型”）；
• 怎么告诉阀门该做什么（Action 字段：转发到端口2、打上VLAN标签、丢弃、送控制室研判…就像“关闭东侧防火门+启动西侧喷淋”）；
• 怎么让阀门上报异常（Upcall：发现不认识的包，立刻喊“报告！这个包没见过，怎么办？”，把包和元数据打包发给控制室）。

而这份笔记里反复出现的ovs-ofctl、ofproto、datapath，全都是围绕这个核心角色展开的：

• ovs-ofctl是你临时客串“控制室值班员”的工具，用命令行直接下发指令（比如ovs-ofctl add-flow br0 "priority=100,ip,nw_src=10.0.0.1,actions=output:2"）；
• ofproto是 OVS 内部的“指令翻译官”，它接收 OpenFlow 协议包，解析出 Match 和 Action，再转成 OVS 自己能懂的内部结构（比如struct rule和struct ofpact）；
• datapath是最终站在一线的“阀门本阀”，它在内核里高速运行，拿着翻译好的指令（流表项），对每个飞过的数据包做毫秒级匹配与执行。

提示：新手最容易混淆的点是把ovs-vswitchd（用户态守护进程）当成“主脑”。其实它更像一个“调度中心+翻译办公室”：它从数据库（ovsdb-server）读配置，跟控制器（Controller）聊天，把高层指令翻译成底层动作，再把动作下发给内核datapath执行。真正的“肌肉”和“反射弧”，永远在datapath模块里。这也是为什么笔记从第3页就开始讲datapath初始化——因为那是数据真正开始流动的地方。

2.1 四个核心组件，就是 OVS 的「四肢躯干」：缺一不可，各司其职

OVS 不是一个单体程序，而是一套精密协作的组件组合。笔记第2页列出的ovs-vswitchd、ovsdb-server、ovs-vsctl、ovs-dpctl，就是它的“心脏、大脑、手、脚”。理解它们的关系，比死记函数名重要十倍：

注意：ovs-ofctl（OpenFlow 控制工具）和ovs-appctl（进程控制工具）没列在上表，因为它们是“临时工”。ovs-ofctl是你代替 Controller 下发指令的“遥控器”；ovs-appctl是你给ovs-vswitchd进程发内部命令的“对讲机”（比如ovs-appctl dpif/show查看 datapath 详细信息）。它们不参与日常配置，但在调试时高频出现。

2.2 为什么必须分“用户态”和“内核态”？——性能与灵活性的生死平衡

这是新手读源码时最大的认知鸿沟：为什么 OVS 要搞这么复杂，把逻辑拆成ovs-vswitchd（用户态）和datapath（内核态）两部分？直接全写在内核里不行吗？答案关乎一个残酷事实：Linux 内核追求稳定和安全，绝不允许任何可能拖慢网络转发的“复杂逻辑”常驻其中。

想象一下：一个数据包以 10Gbps 速度涌入，每秒数百万个包。如果每个包都要在内核里做复杂的 OpenFlow 规则匹配（涉及多字段、掩码、跳转表）、还要跟用户态进程通信、甚至触发 Python 脚本……内核早就崩了。OVS 的设计哲学是：把“快”的事交给内核，把“聪明”的事留给用户态。

• 内核datapath：只做三件事，且必须极快

  1. 收包：从网卡驱动拿到 skb（socket buffer）；
  2. 提 Key：用ovs_flow_key_extract()快速提取包的关键特征（源/目的 MAC/IP/端口等），生成一个紧凑的sw_flow_key结构；
  3. 查流表 & 执行 Action：用这个 Key，在哈希表里极速查找匹配项，找到就执行预设动作（如OVS_ACTION_ATTR_OUTPUT转发到端口）。

  这整个过程，目标是在微秒级完成。所以datapath代码极度精简，避免锁、避免内存分配、避免函数调用栈过深。笔记第3.1.3节讲的flow_lookup()和masked_flow_lookup()，核心就是优化这个查找——用 mask cache 避免重复计算，用分段哈希桶减少冲突。

• 用户态ovs-vswitchd：做所有“慢”但必要的事

  • 解析 OpenFlow 协议（支持多个版本，处理 TLV 编码）；
  • 维护复杂的流表管理（超时、统计、优先级排序）；
  • 与 Controller 保持长连接、处理心跳、同步状态；
  • 当datapath查不到匹配项（Miss），接收 upcall 上来的包，进行深度分析（xlate），生成新流表项并下发回内核；
  • 处理各种高级特性：QoS、隧道封装（GRE/VXLAN）、采样（sFlow）。

  这些事可以慢一点（毫秒级），但必须灵活、可扩展、易调试。用户态天然支持动态加载、日志、调试器 attach，而内核模块一旦出错就是 panic。

所以，当你看到笔记里ovs_dp_upcall()函数（第3.1.8节）把包发给用户态，不要觉得是“失败了”，这恰恰是 OVS 的核心智慧：用内核的“快”兜底基础转发，用用户态的“活”支撑业务创新。两者通过 Netlink（一种高效的内核-用户态通信机制）无缝衔接。这也是为什么笔记第3.1.2节强调genl_family注册——那是内核为datapath开的“专用快递通道”。

2.3 从零搭建你的第一个 OVS 环境：三步验证，确认你已站在起点

光说不练假把式。现在，我们用最简方式，亲手搭一个最小可用的 OVS 环境，并验证datapath是否真在工作。这不是为了生产，而是为了建立“手感”——当你亲眼看到数据包被 OVS 拦截、匹配、转发，那份抽象感就落地了。

步骤 1：安装与基础检查（2分钟）

在 Ubuntu/Debian 系统上（推荐 20.04+），执行：

# 安装 OVS（包含所有组件） sudo apt update && sudo apt install openvswitch-switch openvswitch-common # 启动服务（ovsdb-server 和 ovs-vswitchd 会自动启动） sudo systemctl start openvswitch-switch # 验证服务状态 sudo systemctl status openvswitch-switch # ✅ 应看到 "active (exited)" 或 "active (running)"

步骤 2：创建桥并添加端口（1分钟）

# 创建一个名为 br0 的虚拟交换机（bridge） sudo ovs-vsctl add-br br0 # 查看当前所有桥（应看到 br0） sudo ovs-vsctl show # 添加一个“内部端口”（类似一个虚拟网卡，可配 IP） sudo ovs-vsctl add-port br0 br0-internal -- set interface br0-internal type=internal # 给这个内部端口配 IP（让它能 ping 通） sudo ip addr add 192.168.100.1/24 dev br0-internal sudo ip link set br0-internal up # 查看 br0 的端口状态 sudo ovs-ofctl show br0 # ✅ 应看到类似 "LOCAL(br0-internal): addr:aa:bb:cc:dd:ee:ff" 的输出

步骤 3：注入第一条流表，见证数据流动（3分钟）

这才是关键！我们手动下发一条最简单的流表，让所有进入 br0 的 IP 包，都从br0-internal端口转发出去（即“泛洪”到本机）：

# 查看 br0 当前流表（初始为空） sudo ovs-ofctl dump-flows br0 # ❌ 输出应为空（无流表） # 下发第一条流表：匹配所有 IP 包（priority=100），动作是 output:1（端口1 = LOCAL） sudo ovs-ofctl add-flow br0 "priority=100,ip,actions=output:1" # 再次查看流表（确认已写入） sudo ovs-ofctl dump-flows br0 # ✅ 应看到类似 "cookie=0x0, duration=10.1s, table=0, n_packets=0, ..." 的一行 # 验证：从本机 ping 自己（触发流表匹配） ping -c 3 192.168.100.1 # ✅ 应看到 3 个包全部成功（"64 bytes from 192.168.100.1..."） # 关键验证：看内核 datapath 是否真收到了这条流表？ sudo ovs-dpctl dump-flows # ✅ 应看到类似 "in_port(1),eth(),ip(), actions:1" 的输出！这就是 datapath 里真实运行的流表。

逻辑说明：ovs-ofctl add-flow命令，本质是向ovs-vswitchd发送 OpenFlowOFPT_FLOW_MOD消息。ovs-vswitchd解析后，通过 Netlink 将流表项（struct sw_flow）写入内核datapath的哈希桶。ovs-dpctl dump-flows直接读取内核内存，所以它显示的是“真相”。而ovs-ofctl dump-flows读的是ovs-vswitchd内存中的缓存，有时会有延迟。新手第一次看到ovs-dpctl输出和ovs-ofctl一致，那种“啊，它真的在跑！”的顿悟感，就是入门的临门一脚。

3. 第一个必须读懂的源码片段：ovs_flow_key_extract()—— 数据包的「身份证」是怎么生成的？

前面我们用ping验证了流表生效，但那个ip匹配到底是怎么工作的？它凭什么说这个包是“IP 包”？这就引出了 OVS 最核心的环节：Key 提取（Key Extraction）。笔记第3.1.3节提到的ovs_flow_key_extract()函数，就是这个环节的入口。它不关心包的内容，只负责从原始数据包（skb）里，精准、高效地抠出一组标准化的字段，组成一个sw_flow_key结构。这个结构，就是 datapath 流表匹配的唯一依据，相当于数据包的“身份证”。

为什么必须抠出这些特定字段？因为 OpenFlow 的 Match 字段（如nw_src,tp_dst）是协议定义的，OVS 必须把网络栈里分散在不同层次的字段，统一映射到这个结构里。比如：

• MAC 地址在以太网帧头（L2）；
• IP 地址在 IP 包头（L3）；
• 端口号在 TCP/UDP 包头（L4）；
• VLAN ID 在 802.1Q 标签里（L2.5）。

ovs_flow_key_extract()就是那个“全栈解析器”，它按顺序扫描 skb，根据协议类型层层解包，把需要的字段填进sw_flow_key的对应位置。笔记第9页的struct sw_flow_key图，就是这张身份证的模板。

3.1 白话解读sw_flow_key结构：一张数据包的「标准简历」

笔记第9页的结构体，初看密密麻麻，但拆开就是一份清晰的“包简历”。我们只聚焦最常用的几个字段，用生活化语言解释：

struct sw_flow_key { struct { uint8_t src[ETH_ALEN]; // 【教育背景】本科毕业院校：源MAC地址（6字节） uint8_t dst[ETH_ALEN]; // 【教育背景】硕士毕业院校：目的MAC地址（6字节） uint16_t tci; // 【附加证书】是否持有VLAN证书？tci的低12位就是VLAN ID uint16_t type; // 【专业方向】主修专业：0x0800=IP, 0x86DD=IPv6, 0x8100=VLAN } eth; // 以太网层信息 struct { uint8_t proto; // 【核心技能】精通协议：6=TCP, 17=UDP, 1=ICMP uint8_t tos; // 【工作态度】服务类型（TOS）：影响QoS优先级 uint8_t ttl; // 【职业寿命】生存时间（TTL）：每经过一个路由器减1 uint32_t src; // 【家庭住址】老家IP（IPv4源地址） uint32_t dst; // 【现居地址】现住址IP（IPv4目的地址） } ipv4; // IPv4层信息（如果是IPv6，对应ipv6结构） struct { uint16_t src; // 【联系方式】手机号（源端口） uint16_t dst; // 【联系方式】微信ID（目的端口） } tp; // 传输层信息（TCP/UDP端口） uint32_t recirc_id; // 【内部工号】循环ID：用于OVS内部多阶段处理（高级特性） uint16_t in_port; // 【入职部门】从哪个端口进来的？（如端口1=br0-internal） };

关键点：sw_flow_key是一个扁平化、固定长度的结构。它不存储原始包数据，只存关键索引值。这样做的好处是：流表匹配时，CPU 只需比较几个整数（src,dst,in_port），速度极快。而ovs_flow_key_extract()的任务，就是确保无论包是来自物理网卡、虚拟网卡（tap/veth）、还是隧道（VXLAN），都能被准确“翻译”成这份标准简历。

3.2 动手验证：用tcpdump抓包，对照sw_flow_key看“简历”生成过程

理论不如眼见为实。我们用tcpdump抓一个ping包，再用ovs-dpctl查看 datapath 如何把它“翻译”成 Key：

# 步骤1：在 br0-internal 端口抓包（监听我们刚创建的内部端口） sudo tcpdump -i br0-internal -n -c 2 icmp # ✅ 会看到类似：192.168.100.1 > 192.168.100.1: ICMP echo request (id=12345, seq=1) # 记下这个包的源/目的IP（都是192.168.100.1）、ICMP类型（8） # 步骤2：清空现有流表，确保干净环境 sudo ovs-ofctl del-flows br0 # 步骤3：下发一条精确匹配此 ping 包的流表（只匹配ICMP） sudo ovs-ofctl add-flow br0 "priority=200,icmp,nw_src=192.168.100.1,nw_dst=192.168.100.1,actions=output:1" # 步骤4：再次 ping，触发流表匹配 ping -c 1 192.168.100.1 # 步骤5：查看 datapath 中实际匹配的 Key（核心！） sudo ovs-dpctl dump-flows | grep -A 5 "icmp" # ✅ 输出类似： # in_port(1),eth(),ip(),icmp(),nw_src=192.168.100.1,nw_dst=192.168.100.1, actions:1 # 这就是 datapath 从抓到的包里，用 ovs_flow_key_extract() 提取出的 Key！ # 对比 tcpdump 输出：源IP=192.168.100.1，目的IP=192.168.100.1，协议=icmp（对应proto=1）——完全吻合！

参数说明：ovs-dpctl dump-flows的输出中，in_port(1)是输入端口（br0-internal 的编号），eth()表示匹配任意以太网帧，ip()表示匹配 IP 包，icmp()表示匹配 ICMP 协议，nw_src/nw_dst就是sw_flow_key.ipv4.src/dst字段。你看到的每一个字段，都是ovs_flow_key_extract()从原始 skb 里精准抠出来的。这就是源码笔记的价值：它告诉你，dump-flows里显示的不是魔法，而是ovs_flow_key_extract()这个函数，一行行 C 代码执行的结果。

3.3 常见问题排查：为什么我的流表“看起来匹配”，但包就是不转发？

这是新手踩坑率最高的问题。现象、原因、解决，我们一条条拆解：

现象 1：ovs-ofctl dump-flows显示有流表，ovs-dpctl dump-flows却为空

原因：流表只写入了ovs-vswitchd的用户态缓存，但未成功下发到内核datapath。常见于ovs-vswitchd进程崩溃、或datapath模块未正确加载。
解决：

# 1. 检查 ovs-vswitchd 是否存活 sudo systemctl status openvswitch-switch # 2. 检查内核模块是否加载 lsmod | grep openvswitch # ✅ 应看到 openvswitch, nf_conntrack, nf_defrag_ipv6 等 # 3. 强制重载 datapath 模块（谨慎，会中断网络） sudo modprobe -r openvswitch && sudo modprobe openvswitch sudo systemctl restart openvswitch-switch

现象 2：ovs-dpctl dump-flows显示流表，但ping无响应，ovs-appctl dpif/show显示n_misses=0（未命中）

原因：流表的in_port匹配错了。ovs-ofctl add-flow默认匹配所有端口，但ovs-dpctl dump-flows显示的in_port(1)是 datapath 内部端口编号，不是ovs-vsctl show里看到的端口名。
解决：

# 查看 datapath 端口真实编号 sudo ovs-dpctl show # ✅ 输出类似： # system@ovs-system: hit:0 missed:0 lost:0 # port 0: ovs-system (internal) <-- 这是LOCAL端口，编号0 # port 1: br0-internal (internal) <-- 这是我们加的端口，编号1 # 所以，流表必须明确指定 in_port=1 sudo ovs-ofctl add-flow br0 "priority=200,in_port=1,icmp,actions=output:1"

现象 3：流表匹配成功（n_packets>0），但包被丢弃（ovs-appctl dpif/show显示n_dropped>0）

原因：Action 动作无效。最常见的是output:2，但端口2不存在或未启用。
解决：

# 1. 查看所有端口编号 sudo ovs-dpctl show # 2. 确保 Action 中的端口号存在且 UP sudo ip link show br0-internal | grep "state" # ✅ 应看到 "state UP" # 3. 用最保守的 Action 测试：output:1（本端口回环） sudo ovs-ofctl add-flow br0 "priority=300,ip,actions=output:1" ping -c 1 192.168.100.1 # 应成功

现象 4：ovs-dpctl dump-flows显示流表，但tcpdump -i any抓不到包

原因：包被datapath处理后，直接在内核里转发了，没有经过用户态协议栈（any接口抓不到）。这是正常行为！
验证：改用tcpdump -i br0-internal抓内部端口，或tcpdump -i eth0（如果你把物理网卡加入了 br0）。

4. 从“能跑”到“真懂”：避坑指南——新手读 OVS 源码必踩的 4 个深坑

读源码不是翻字典，而是一场充满陷阱的探险。我第一次跟着这份笔记读datapath初始化时，在dp_init()函数里卡了整整两天，就因为掉进了下面这些坑。现在把血泪经验总结成 4 条，帮你绕开弯路：

坑 1：死磕module_init(dp_init)，却忽略了datapath的“双重身份”

现象：在datapath.c里找到dp_init()，看到register_pernet_device(&ovs_net_ops)就以为初始化完了，但后续ovs_vport_receive()收不到包。
原因：datapath模块有两个初始化入口：

• module_init(dp_init)：注册 Netlink family，让内核知道“有 OVS 这个服务”；
• pernet_operations的init函数（ovs_net_init）：为每个网络命名空间（network namespace）创建独立的datapath实例。这才是真正干活的初始化！笔记第3.1.2节只提了前者，后者藏在ovs_net_ops结构体里。
  解决：

// 在 datapath.c 中，找到 ovs_net_ops 定义 static struct pernet_operations ovs_net_ops = { .init = ovs_net_init, // 👈 真正的初始化函数！ .exit = ovs_net_exit, .id = &ovs_net_id, .size = sizeof(struct ovs_net), }; // 进入 ovs_net_init()，你会看到： // - 分配全局的 flow_table（流表哈希桶） // - 初始化 genl_family（Netlink 通信） // - 注册 vport 类型（如 netdev, internal） // 这才是 datapath “活过来”的时刻。

教训：module_init只是“注册上岗”，pernet init才是“分配工位”。读初始化，必须两条线一起跟。

坑 2：把ovs_flow_key_extract()当成“万能解析器”，却不知它有“短路逻辑”

现象：给一个带 VLAN 的包下发vlan_tci=100的流表，但dump-flows显示vlan_tci=0，匹配失败。
原因：ovs_flow_key_extract()有严格的协议栈解析顺序。它先看以太网帧头，如果type字段是0x8100（VLAN），才会继续解析 VLAN 标签，把tci填入sw_flow_key.eth.tci。但如果包是0x0800（IP），它就直接跳过 VLAN 解析，tci保持为 0。VLAN 标签必须在以太网帧头里，且 type 正确，才能被识别。
解决：

• 确保发送包的设备（如veth对）启用了 VLAN 协议：sudo ip link add link eth0 name eth0.100 type vlan id 100；
• 或用ovs-ofctl强制添加 VLAN：sudo ovs-ofctl add-flow br0 "priority=100,actions=push_vlan:0x8100,set_field:100->vlan_vid,output:2"。

坑 3：对着sw_flow_key结构体找字段，却忘了“字段存在性”由mask决定

现象：流表写了nw_src=10.0.0.1，但dump-flows显示nw_src=0.0.0.0/0，匹配总是失败。
原因：sw_flow_key里的字段只是“容器”，真正决定哪些字段参与匹配的，是sw_flow_mask（掩码）。笔记第3.1.4节的struct sw_flow_mask结构体，就是用来标记“哪些位需要比较”。如果mask里nw_src对应的位是 0，那么key.nw_src的值再大也没用，匹配时会被忽略。
解决：

# 查看当前流表的完整 mask（需要 debug 版本） sudo ovs-appctl dpif/show | grep -A 10 "mask" # 或用更直观的方式：下发流表时，显式指定 mask sudo ovs-ofctl add-flow br0 "priority=100,ip,nw_src=10.0.0.1/255.255.255.255,actions=output:1" # 👈 /255.255.255.255 就是告诉 OVS：nw_src 字段必须全匹配，mask 全 1。

坑 4：在ovs-vswitchd里找datapath交互，却不知道dpif是“中间人”

现象：想搞懂ovs-vswitchd怎么把流表发给内核，但在vswitchd/目录下找不到netlink相关代码。
原因：ovs-vswitchd和datapath之间，隔着一个抽象层叫dpif（Datapath Interface）。笔记第2节提到的ofproto-dpif，就是ofproto层调用dpif的接口；而dpif的具体实现（如dpif_netlink）才真正封装了 Netlink 通信。vswitchd/目录下只有dpif的调用，lib/dpif-netlink.c里才有netlink的 send/receive 逻辑。
解决：

• 读vswitchd/bridge.c里的bridge_reconfigure()，找到ofproto_create()；
• 进入ofproto-dpif.c，找到dpif_operate()调用；
• 最终跳转到lib/dpif-netlink.c的dpif_netlink_operate()，这里就是sendmsg()发 Netlink 消息的地方。

血泪经验：OVS 的分层太

本文还有配套的精品资源，点击获取