企业官网建设流程全解析

简介：OpenvSwitch（OVS）源码阅读笔记是一份面向网络虚拟化初学者的代码导读资料，围绕OVS 2.3.90版本的核心模块展开，适合希望理解虚拟交换机工作原理与OpenFlow落地实现的开发者。内容从OVS网络架构切入，依次梳理ovs-vswitchd、ovsdb-server、ovs-vsctl、ovs-ofctl等组件，再深入ofproto、netdev与内核态datapath，讲解数据包收发、流表哈希桶、流表创建等关键流程。笔记按网络架构、内部组件、代码实现三部分组织，便于循序渐进对照阅读。从Vport收包、OVS key生成到哈希桶初始化与动作执行，笔记均按源码调用顺序逐步追踪，完整还原数据包在OVS中的处理链路。笔记以代码片段和数据结构为主线，帮助读者看清用户态与内核态的协作关系，掌握流表匹配、upcall上报、OpenFlow控制器下发规则等机制，为SDN实践或二次开发打下基础。整个资源包仅1个PDF文件，大小约1012KB，便于直接阅读收藏。目前已有976人学习。

1. 读Open vSwitch源码前先画三层地图：内核datapath、用户态vswitchd与OpenFlow协议面

Open vSwitch（以下简称OVS）源码阅读笔记跟其他网络项目最大的差别在于：它不是一个单一进程，而是“内核数据面 + 用户态控制面 + OpenFlow协议面”三层的组合。底层是内核里的datapath模块，负责流表匹配和报文转发；中间是用户态的ovs-vswitchd守护进程，负责配置同步与OpenFlow管理；上层则是OpenFlow协议本身，让SDN控制器能远程下发流表，统一管理接入的虚拟机与设备。三条线不是孤立的：数据包从网卡进来后，先走datapath快速路径，匹配不到才通过upcall送到用户态，由vswitchd查OpenFlow流表后把结果反写内核。这份笔记围绕这条主链路展开，覆盖OVS 2.3.90版本重点模块的源码实现流程，适合正在啃OVS源码的初级读者，也适合复习OpenFlow与SDN数据面原理的人查漏补缺。

2. datapath内核模块：从收包、流表匹配到action执行的四个关键环节

datapath是OVS的内核模块，负责从vport接收报文、在流表里做匹配、按匹配到的action处理。一个datapath可以对应多个vport，vport的概念类似物理交换机的端口；一个datapath关联一张flow table，flow table的每个条目包含两部分：match/key和action。阅读datapath时建议按“初始化入口 → 收包回调 → 查表 → 动作/上送”四步走，下面逐节展开。

2.1 模块初始化与收包回调链：dp_init挂接genl_family与vport接收函数

内核模块采用module_init(dp_init)进行初始化。dp_init中datapath的genl_family注册了四类操作，分别对应datapath、vport、flow、packet的netlink通信。用户态通过这套genl接口下发流表、配置端口，内核也通过它上报upcall数据。注册完成后，vport侧注册收包回调函数，整个收包链是固定的三段式：netdev_frame_hook() 先收到报文，然后调用netdev_port_receive() 做入端口处理，最后进入ovs_vport_receive()。真正干活的是ovs_dp_process_packet()：先用ovs_flow_key_extract() 从报文的Ethernet帧中提取flow的key内容，生成sw_flow_key，这个key相当于报文的“特征指纹”，接下来所有流表匹配都是拿它去比对。

划重点：vport层只负责“收上来”，不负责“怎么处理”。收包处理和流表匹配是解耦的，换一种vport类型（比如tap、internal、dpdk）不影响后续查表逻辑。这个解耦是OVS内核模块能适配多种虚拟化场景的基础。

2.2 流表哈希桶与流表创建：flex_array内存布局与RCU保护

流表采用哈希方式存放，hash头结点用hlist_head组织。哈希桶由alloc_buckets() 初始化，底层存储用flex_array结构：flex_array把元素空间按页划分，每页存放elems_per_part个元素，parts指针数组指向每一页，当元素空间超过FLEX_ARRAY_BASE_BYTES_LEFT时再分配下一页。用flex_array而不是直接kmalloc大数组的原因在于：流表项数量动态变化时，不需要一次性分配大块连续内存，且地址计算通过reciprocal_elems做快速除法取模，性能有保障。

用户态通过netlink下发OVS_FLOW_CMD_NEW创建流表，内核侧入口是dp_flow_genl_ops中的ovs_flow_cmd_new函数。创建完成后，流表的核心数据结构关系如下表：

这里有一个容易混淆的点：flow_table和table_instance是分离的。table_instance可以整体替换，替换时通过RCU保证正在查询的读者不会读到半更新状态。扩桶、缩桶时，老的table_instance不会立刻释放，而是等所有读者退出临界区后才回收，这是内核态并发场景下的经典做法。

2.3 流表查询路径：mask_cache分段查询与masked_flow_lookup

流表查询的入口是ovs_flow_tbl_lookup_stats()。OVS的匹配策略比较“朴素”：把这个key和流表中所有mask、所有key逐一比对。朴素归朴素，真正执行前有一个重要加速机制——mask_cache。

mask_cache是per-cpu的缓存数组，缓存的是“最近查询成功用到的mask”。查询时先看缓存的mask_cache_entry，命中缓存就只对这个mask做一次快速匹配，避免遍历全部mask；缓存未命中才进入flow_lookup() 做全量遍历。查询逻辑用伪代码更容易理解：

/* 流表查询入口：mask_cache命中则快速路径，否则全量遍历 */ struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl, struct sw_flow_key *key, u32 *n_mask_hit) { struct mask_cache_entry *ce; struct sw_flow *flow; ce = mask_cache_enter(tbl, key); /* 从per-cpu缓存取一个mask */ if (ce->mask) { /* 缓存命中：只拿这一个mask做一次掩码匹配 */ flow = masked_flow_lookup(tbl, key, ce->mask); if (flow) { (*n_mask_hit)++; return flow; /* 快速路径直接返回 */ } } /* 缓存未命中：遍历mask_array里的全部mask，逐一遍历 */ return flow_lookup(tbl, key, n_mask_hit); }

masked_flow_lookup() 负责把key按mask切分后与流表项比对，flow_lookup() 负责遍历所有mask调用这段逻辑。梳理下来会发现，OVS这里把“查哪个mask”和“怎么查key”拆成了两层，缓存只负责前者。最容易忽略的是：mask_cache缓存的是mask本身，不是流表项的缓存，流表项是否命中仍然取决于key做完mask运算之后是否和流表项里存储的key相等。

2.4 action执行与upcall：命中后的动作链与未命中时的netlink上送

流表匹配成功后，进入action处理。入口是do_execute_actions()，它从netlink属性里循环取出action，按nla_type() 分发到具体函数。OVS 2.3.90里常见的action类型整理成对照表：

/* do_execute_actions()的switch分发骨架 */ for (a = attr, rem = len; rem > 0; a = nla_next(a, &rem)) { switch (nla_type(a)) { case OVS_ACTION_ATTR_OUTPUT: do_output(dp, skb, key, nla_get_u32(a)); break; case OVS_ACTION_ATTR_SET: execute_set_action(skb, nla_data(a)); break; case OVS_ACTION_ATTR_RECIRC: /* 不立即执行，存入action_fifos延迟处理 */ break; } }

RECIRC值得单独说：它不立即执行动作，而是把action挂到全局的action_fifos数组里，作为deferred_action稍后处理。这在理解“重入查表”和“多级流表”场景时很关键。USERSPACE和SAMPLE这两类action是内核主动把报文交给用户态的通道，不要把它们和“未命中”混为一谈。

流表未命中时，内核走ovs_dp_upcall()，调用queue_userspace_packet() 构造发往用户态的skb，通过netlink发送到用户层。上送报文的核心布局是：nlmsghdr + genlmsghdr + ovs_header，随后依次放置OVS_PACKET_ATTR_KEY（key信息）、OVS_PACKET_ATTR_USERDATA（用户数据）、OVS_PACKET_ATTR_PACKET（原始数据包）。数据拷贝采用skb_zerocopy() 避免不必要的内存复制。这条路径是第3章udpif的输入源头，记住“未命中才会触发MISS_UPCALL”是理解用户态工作量的前提。

3. 用户态三件套：vswitchd、ofproto与udpif如何协作

用户态代码在vswitchd/目录下，比内核态复杂不少，但核心只有三个：vswitchd主循环、ofproto接口层、udpif多线程。vswitchd负责全局调度，ofproto负责OpenFlow接口抽象，udpif负责消费内核送上来的upcall并把结果写回内核。

3.1 vswitchd主循环：从main()到bridge_run()的事件驱动骨架

vswitchd是OVS主要的用户态程序，它从ovsdb-server读取配置并发送到ofproto层，也把ofproto层产生的状态和统计信息写回数据库。整体流程从main() 函数入手：

/* vswitchd main()简化流程：初始化 + 事件循环 */ int main(int argc, char *argv[]) { remote = parse_options(argc, argv, &unixctl_path); daemonize_start(); /* 进入守护进程模式 */ unixctl_server_create(unixctl_path, &unixctl); bridge_init(idl); /* 初始化桥模型与数据库IDL */ while (true) { bridge_run(); /* controller交互 + ofproto运行 */ unixctl_server_run(unixctl); /* 处理ovs-appctl命令 */ netdev_run(); /* 刷新虚拟网卡状态 */ bridge_wait(); unixctl_server_wait(unixctl); poll_block(); /* 阻塞直到fd事件或超时 */ } }

bridge_run() 是整个循环的核心，展开后还有多层：ovsdb_idl_run() 负责运行数据库连接；bridge_init_ofproto() 负责初始化和注册ofproto接口类（关键的是ofproto_dpif_class）；bridge_run__() 调ofproto_run() 真正跑ofproto逻辑，内部还会调ofproto_enumerate_types() 和dp_initialize() 注册dpif_class（dpif_netlink_class、dpif_netdev_class）；bridge_reconfigure() 负责把ovsdb的cfg配置同步过来，包括网桥创建、端口添加、控制器连接。

值得留意的是bridge_reconfigure() 里的端口创建链路：bridge_add_ports() → iface_create() → iface_do_create() → ofproto_port_add() → ofproto_class->port_add() → dpif_port_add() → dpif_netlink_port_add()，最后通过netlink配置到内核datapath。也就是说，用户态创建一个端口，本质上是在把配置“翻译”成netlink消息下发到内核，用户态与内核态通过netlink这一条通道完成所有配置同步。

3.2 ofproto接口层：ofproto、ofport、ofrule、ofgroup四个对象

ofproto是OpenFlow的接口层，负责和OpenFlow controller通信，并通过ofproto_class与底层交互，ofproto_dpif是它的具体实现。ofproto层一共包含四个核心接口对象：

ofproto_dpif是ofproto的具体实现，它内部还持有dpif_backer、sflow对象。dpif层又分dpif_netlink_class和dpif_netdev_class两种实现：dpif_netlink走内核datapath，dpif_netdev是纯用户态数据面。阅读代码时注意ofproto → ofproto_dpif → dpif_backer → dpif这条继承链，很多回调就是在这条链上一层层注册的。

ofproto创建流程也可以拉成一条链：bridge_init_ofproto() → ofproto_init() → bridge_reconfigure() → ofproto_create()。ofproto_create里先ofproto_class_find__() 找到ofproto_dpif_class，然后alloc() 分配ofproto_dpif对象，connmgr_create() 创建连接管理器，construct() 回调里再open_dpif_backer() 打开datapath（内部是dpif_class->open、udpif_create）、ofproto_init_tables() 初始化流表并add_internal_flows() 添加内部流，最后init_ports() 创建ofport。ofport的创建又走netdev_open() → netdev_linux_alloc() → netdev_linux_construct()，最后ofport_install() 完成安装。

3.3 udpif多线程模型：upcall从接收到xlate_actions的转换

udpif是用多线程处理内核upcall的接口层，入口是udpif_set_threads()。它调用udpif_start_threads() 分配handlers空间，用ovs_thread_create() 创建n_handlers个线程，每个线程的回调是udpif_upcall_handler()。线程内部主循环是：

recv_upcalls() → dpif_recv() → dpif_netlink_recv() → dpif_netlink_recv__() → epoll_wait() 阻塞等待upcall数据 → nl_sock_recv() 把数据放入ofpbuf → parse_odp_packet() 转成dpif_upcall结构 → odp_flow_key_to_flow() 把key转成flow → flow_extract() 根据packet和metadata设flow参数 → upcall_receive() 构造upcall结构 → process_upcall()。

process_upcall() 之后最重要的分支是MISS_UPCALL（流表未命中的上送），进入upcall_xlate()：先xlate_in_init() 初始化xlate_in，再xlate_actions() 生成dp需要的xlate_out。xlate_actions里先rule_dpif_lookup() 在流表中找rule，rule_dpif_get_actions() 取出rule中的actions，do_xlate_actions() 逐个翻译action。翻译完还有两个收尾分支：如果upcall的xout.fail_open模式使能，调用ofproto_dpif_send_packet_in() 发送ofproto_packet_in消息到控制器；如果xout.slow存在，调用compose_slow_path() 增加慢速路径的action到xlate_out。最后handle_upcalls() 统一通过dpif_operate()（实际是dpif_netlink_operate()）把处理结果写回内核datapath。对于DPIF_UC_MISS，还会调用ukey_create_from_upcall() 创建udpif_key。

这里需要区分两个“下发”：xlate_actions是用户态翻译动作，dpif_operate是把翻译结果写回内核。整个udpif层就是一条“内核upcall → 用户态翻译 → 反写内核”的环路，线程模型解决的是这条环路的并发吞吐问题。

4. OpenFlow协议侧：连接管理、flow_mod报文与match/instruction解析

OpenFlow是OVS的管理协议，ovs-ofctl是OVS自带的命令行工具。在没有配置OpenFlow controller的模式下，用户可以用ovs-ofctl连接OVS，创建、修改、删除流表项，并监控运行状况。这一章从连接建立、报文格式、字段解析三个角度梳理协议侧的源码逻辑。

4.1 ofconn与ofservice：主动发起与被动监听的连接骨架

OpenFlow连接由bridge_reconfigure() 里的bridge_configure_remotes() 处理，主要创建两个对象：ofconn作为客户端负责和远端controller主动建立连接；ofservice作为服务器提供被动监听。

主动连接（以TCP为例）的函数调用链是：connmgr_set_controllers() → add_controller() → ofconn_create() → rconn_connect() → reconnect() → vconn_open() → vconn_stream_open()（tcp_vconn_class->open）→ stream_open_with_default_port() → stream_open() → tcp_open() → inet_open_active() → socket() → connect() → new_tcp_stream() → new_fd_stream() → vconn_stream_new()。链虽长，模式很固定：vconn是对vconn_class的抽象，stream是对stream_class的抽象，每层只做一次“向下转型+回调”，最终落到socket系统调用。

被动监听（以unix socket为例）的链路是：connmgr_set_controllers() → ofservice_create() → pvconn_open() → pvconn_pstream_listen()（unix_vconn_class->listen）→ pstream_open_with_default_port() → pstream_open() → punix_open()（punix_pstream_class->listen）→ make_unix_socket() → inet_open_passive() → socket() → bind_unix_socket() → listen() → new_fd_pstream() → pstream_init()。两条链路最后收敛到rconn_create() → ofconn_create()，区别是ofconn类型不同（主动是OFCONN_PRIMARY，被动是OFCONN_SERVICE）。

报文处理的入口统一在ofproto_run() → connmgr_run()。ofconn相关：ofconn_run() → rconn_run() → vconn_run() → vconn_stream_run() → vconn_stream_send() → stream_send()，接收侧走rconn_recv() → vconn_recv() → vconn_stream_recv() → stream_recv() → fd_recv() → recv系统调用。ofservice相关：pvconn_accept() → pvconn_pstream_accept() → pstream_accept() → pfd_accept() → accept() → punix_accept() → new_fd_stream() → stream_init() → rconn_create() → ofconn_create()，新ofconn插入all_conns链表，下一次connmgr_run()就轮到它处理报文。这个“先接受、再处理”的两段式设计，阅读时不要漏掉。

4.2 flow_mod报文结构：openflow头部、match与instruction的分层解析

OpenFlow协议消息的处理入口是handle_openflow()，最重要的消息是flow_mod（流表项修改）。flow_mod报文格式由四部分组成：openflow头部、flow_mod固定字段、match字段、instruction字段。match分为OFPMT_STANDARD和OFPMT_OXM两种类型，一个match里可以包含多个oxm；instruction可以包含多个action，也可以没有。

这个结构的分层是理解解析代码的关键。match字段的解析入口是ofputil_pull_ofp11_match()，核心处理是nx_pull_raw()：先解析出flow_mod的match字段，然后对match相关参数做合法性检测，最后用解析出的value更新flow中的match。instruction字段的解析入口是ofpacts_pull_openflow_instructions()，decode_openflow11_instructions() 把instruction按不同类别放入ofp11_instruction *insts[N_OVS_INSTRUCTIONS]数组，N_OVS_INSTRUCTIONS根据OVS_INSTRUCTIONS宏推导为6，也就是instruction支持的所有类型。

梳理下来会发现，OVS把match和instruction两个区域的解析完全拆开：match负责“匹配域”（字段+值+mask），instruction负责“动作集”（meter、actions、goto_table等）。这正好对应OpenFlow流表项两段式定义，调试时如果flow_mod插入失败，先用抓包工具确认是match解析报错还是instruction解析报错，能省不少时间。

4.3 OXM-TLV匹配域解析与六种instruction的处理映射

目前match匹配域用得较多的是OXM，即TLV格式。OXM TLV头部结构如下表：

解析函数是nx_pull_match_entry()：先在all_nxm_fields中查找header相等的nxm_field，再根据mf_field_id找到mf_field（字段元数据），然后进入nx_pull_entry__() 做四道检测：

/* nx_pull_entry__()的四个检测步骤（流程示意） */ /* 1. 依赖检测：确定字段满足flow中已有条件 */ if (!mf_are_prereqs_ok(field, &match->flow)) return OFPERR_OFPBIC_BAD_PREREQ; /* 2. 重复检测：确定字段在flow中不存在 */ if (mf_is_all_wild(field, &match->wc)) return OFPERR_OFPBIC_DUP_FIELD; /* 3. 有效性检查：mask和value范围是否合法 */ if (!mf_is_mask_valid(*field, mask) || !mf_is_value_valid(*field, value)) return OFPERR_OFPBIC_BAD_FIELD; /* 4. 写入match：根据value和mask设置match */ mf_set(field, &value, &mask, match);

四道检测的顺序是固定的，任何一道失败都会返回对应的OpenFlow错误码。实际调试中遇到OFPERR_OFPBIC_BAD_PREREQ，优先查前置条件；遇到BAD_FIELD，优先查value范围。

instruction侧的核心是宏OVS_INSTRUCTIONS，它完成了指令类型到处理函数的映射，整理成表：

读这一段时建议对照抓包结果看：抓包里flow_mod的二进制内容，正好能按“openflow头部 → 固定字段 → match（OXM TLV序列） → instruction（类型+长度+action序列）”四段切开，和代码解析路径一一对应。先抓包再读代码，比直接看函数省力得多。

5. 易漏点与易错点：读OVS源码时五个容易翻车的地方

读这套源码过程中踩过的坑集中在几个点上：不是代码难度的问题，而是“以为懂了A，结果漏了B”。下面五条按「易漏点 → 为什么漏 → 怎么补」展开。

5.1 漏了ovsdb-server的配置链路：ovs-vswitchd只是执行者不是决策者

易漏点：只盯着ovs-vswitchd的bridge_run() 看，以为所有配置都在这里生成。

为什么漏：bridge_run() 里的逻辑很重，容易让人忽略它的所有输入都来自ovsdb_idl，而ovsdb-server才是配置源头。ovs-vsctl修改的配置先写入ovsdb-server，ovs-vswitchd通过ovsdb_idl_run() 持续同步，bridge_reconfigure() 再根据同步结果执行网桥创建、端口增删、控制器连接。如果只读vswitchd代码，很容易把配置来源搞错。

怎么补：读代码前先跑一遍ovs-vsctl add-br和ovs-vsctl add-port，然后用strace观察它连接的socket，再回来看bridge_init() 里ovsdb_idl_create() 的参数和ovsdb_idl_omit_alert() 的用法，配置链路就清楚了。

5.2 漏了netdev抽象层：把端口直接理解成Linux网卡

易漏点：看到ofport关联一个netdev，就想当然认为netdev就是eth0。

为什么漏：netdev是OVS的网络设备抽象，netdev_class定义了netdev-provider需要支持的接口，具体的netdev_linux_class、netdev_internal_class、netdev_tap_class、dpdk_class分别对应不同实现。ofport关联的是“抽象的设备对象”，不是直接的net_device。用户态通过netdev_open() 打开设备时，实际做的是netdev_linux_alloc → netdev_linux_construct这套回调，和内核的net_device注册是两回事。

怎么补：梳理netdev_initialize() 里注册的几种class，再对比netdev_open() 在system类型下如何一步步走到netdev_linux_alloc → netdev_linux_construct，就能看到抽象层和具体实现的分界在哪里。

5.3 混淆datapath流表和OpenFlow流表：两套流表、两级缓存

易漏点：看到“流表”两个字就默认是OpenFlow流表。

为什么漏：datapath内核里也有一张flow table，key是ovs_flow_key_extract() 提取的报文特征，表项是sw_flow；OpenFlow侧的流表是ofproto管理的oftable，表项是ofrule加actions。内核datapath流表是“加速缓存”，OpenFlow流表是“规则源”，用户态通过upcall把MISS报文翻译成datapath流表下发内核。读代码时这两个名字都叫flow table，非常容易串。

怎么补：分别执行ovs-ofctl dump-flows和ovs-dpctl dump-flows，对比输出字段差异，两套流表的关系一目了然。ovs-ofctl看到的是OpenFlow规则，ovs-dpctl看到的是内核实际生效的匹配项。

5.4 漏了慢速路径：xout.slow、compose_slow_path与fail_open

易漏点：只看do_xlate_actions() 的动作翻译，忽略xlate_actions() 末尾的slow判断。

为什么漏：大部分action能直接翻译成内核datapath动作，但遇到内核不支持的动作、需要控制器介入的情况，必须走慢速路径。xout.slow存在时调compose_slow_path() 把慢速action拼进xlate_out；fail_open模式使能时调ofproto_dpif_send_packet_in() 把packet_in发到控制器。很多新手读完xlate_actions就以为动作翻译结束了，实际还有这段收尾逻辑。

怎么补：阅读时把xlate_actions() 分成“翻译主循环”和“slow/fail_open收尾”两段，分别标注触发条件。调试时用ovs-appctl查看日志，确认报文走了快速路径还是慢速路径。

5.5 以为upcall只属于MISS：SAMPLE、sflow和USERSPACE同样触发上送

易漏点：把upcall和流表未命中画等号。

为什么漏：OVS_ACTION_ATTR_USERSPACE会把报文直接上送用户态，OVS_ACTION_ATTR_SAMPLE会按概率采样上送（sflow依赖这个机制）。这些不是未命中也会触发upcall。内核侧queue_userspace_packet() 不看“是否MISS”，只看“有没有USERSPACE动作”。如果只关注MISS_UPCALL路径，采样和监控相关代码就读不懂。

怎么补：翻一下do_execute_actions() 里USERSPACE和SAMPLE两个case的处理，再对照dpif_sflow_run() 和dpif_ipfix_run() 在vswitchd主循环里的位置，把“采样上送”这条旁路补进自己的知识地图。

6. 复习清单：把OVS源码笔记变成自己的知识地图

复习时最忌讳的是按源码目录从头到尾翻一遍，翻完发现什么都没留下。建议按下表做三次“自顶向下”自查：

每次自查后，建议在纸上画两条链路。一条是“配置下发链”：从ovs-vsctl开始，到ovsdb-server、ovs-vswitchd、netlink，最后到内核datapath；另一条是“数据包处理链”：从vport收包、key提取、mask_cache查表、action执行或upcall上送、用户态xlate后反写内核。这两条链能独立画出来，这份源码笔记才算真正读透了。

最容易后悔的一件事是刚开始贪多，直接去读action处理部分，结果被do_execute_actions() 的switch分支绕晕。后来把顺序调整为“先画架构图 → 再读datapath四步 → 再读用户态三件套 → 最后回到OpenFlow协议”，整个体系一下子就顺了。从那以后我每次读系统软件源码，都强制先走一遍“组件清单 — 主循环 — 回调链”的流程，再深入细节。希望这份梳理能帮你在读OVS源码时少走这段弯路。

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