OpenVSwitch实现浅谈（四）

根据OpenVSwitch的转发流程，OpenVSwitch需要维护三个数据：Microflow cache，Megaflow cache和OpenFlow Table。前面介绍的是这三个数据之间的关系以及在转发过程中的作用。这部分来看看OpenVSwitch如何管理这三组数据。

OpenFlow Table

从OpenVSwitch的角度来说，OpenFlow的管理是简单的。因为OpenFlow是由SDN controller管理，OpenVSwitch只是提供了OpenFlow增删改查的接口。

Megaflow Cache

前面介绍了Megaflow cache的生成过程。但是生成了之后，还面临着更新和删除。对于更新来说，如果SDN controller更新了OpenFlow Table，那么同一个网络包经过OpenFlow pipeline的处理，得出来的datapath actions可能发生变化，对应的megaflow cache也需要更新。理想情况下，OpenVSwitch能够对于特定的事件，的确定哪些megaflow需要更新。这在有些场景容易达成，比如说通过匹配MAC地址转发到固定的端口（二层交换机特性），当发现MAC地址迁移到了其他的端口，那么只需要更新匹配了对应MAC地址的megaflow cache就可以。但是由于OpenFlow的通用性，大部分更新的场景不能容易的识别对应的megaflow cache。通常情况下，如果在一个OpenFlow Table中增加了一条OpenFlow规则，任何通过这个OpenFlow Table生成的，且用到了优先级更低的OpenFlow规则的megaflow cache都可能表现出不同的行为，都有可能需要更新。如果考虑到OpenFlow Tables组成的pipeline，这个问题将更加的复杂。

早期的OpenVSwitch将megaflow cache分为两组：组cache，当有OpenFlow规则变化时，所有的cache内容都送回到ovs-vswitchd进行重新计算，以确保它们是新的。第二组cache，通过tag标识变化，将变化与megaflow cache关联起来。例如将MAC地址与magaflow cache联系起来，当MAC发生变化时，通过tag查找到相应的magaflow cache，并更新它。随着SDN应用的越来越复杂，tag也越来越复杂，终，在OpenVSwitch 2.0，tag标识被废弃，只剩下组cache。现在，当有任何变化的时候，整个megaflow cache都会被重新计算。

这看起来是非常低效的，但是好在现在的服务器都是多核，且性能在不断提升。在OpenVSwitch 2.0中，ovs-vswitchd被设计成了多线程，可以充分利用多核CPU。并且多线程的设计可以避免重新计算megaflow cache时，阻塞新的megaflow cache下发。新的megaflow cache下发直接决定了网络连接的性能，所以不能阻塞这个过程。通过把更新megaflow cache和下发新的megaflow cache的程序被放到不同的线程，可以让两个流程谁也不阻塞谁。

默认情况下，重新计算（revalidator）的线程数是：CPU核数/4 + 1。下发新的megaflow cache（handler）的线程数是：CPU核数 - revalidators占用的核数，这样可以充分利用主机的CPU。在一个数千虚拟机规模的环境中，ovs-vswitchd的CPU消耗在10%左右，连一个核的CPU都消耗不了。下面是一个48U主机的OpenVSwitch线程数分配值。

# ovs-appctl memory/show
handlers:35 ofconns:2 ports:6 revalidators:13 rules:735