惠伟：openstack网络设计-(一)试探zhuanlan.zhihu.com
惠伟：openstack网络设计-(二)underlay网络zhuanlan.zhihu.com
offload就是ovs转发时用硬件的功能，少耗费host的cpu，这就要求虚拟机和硬件之间能直接交互报文，报文就不用经过host的cpu，ovs只负责给硬件下发转发规则。
硬件资源是有限的，ovs不可能事先把所有转发规则下给硬件，这就要求有一种触发机制，一个报文来了触发ovs给硬件下转发规则，后续报文由硬件转发不再经过ovs，
既然报文是虚拟机和硬件之间直接交互，现在要求硬件把搞不定的报文上送给ovs，这需求一个上送通道，mellanox有个vf representor就是干这事的，vf representor类似于vf，
绑定在ovs桥上，在ovs看来就是一个port，硬件把报文内存，中断触发vf representor，ovs相当于收报文，然后处理。
不想让硬件把报文上送ovs，就要求硬件能搞定尽量多的功能，如openflow查找，qos功能，connection-track功能，vxlan encap/decap功能，nat等。如果硬件搞不定所有功能就只能是partial offload，那些功能offload了哪些功能没有offload，硬件和软件得同步，就拿linux checksum offload来说，skb搞出几个成员专门用来记录信息，如果partial offload，skb/mbuf又得搞出多少成员同步硬件和软件的信息，搞来搞去还不如不offload算了。
硬件是pcie卡，虚拟机和硬件之间通过DMA功能交互报文，vf DMA到虚拟机内存中，vf representor DMA到物理机内存。
sr-iov
图中绿色的是vf，黄色的是vf representor，红色的是pf。
虚拟机和硬件之间能直接交互报文首先想到的就是sr-iov加passthrough功能。
sr-iov功能要求虚拟机中安装厂商要求的driver，其次不支持热迁移，要热迁移虚拟机中driver更负责，不能用于生产环境。
ovs调用tc_flow，tc_flow再调用厂商driver下转发规则。
kernel
sr-iov功能要求虚拟机中安装厂商的driver，假设虚拟机中继续用virtio driver，backend用vhost-net， guest和host之间通过virtio descriptor共享内存，
内存vhost_net模块把virtio descriptor交给ovs模块，ovs模拟再把virtio descriptor转换成mellanox vf能识别的descriptor，太复杂。
vhost-net不可能直接操作vf，必须交给ovs模块，ovs再操作vf，两个模块，内核开发难度太大，没看到mellanox的参数代码。
ovs调用tc_flow，tc_flow再调用厂商driver下转发规则。
dpdk
原生dpdk方案，ovs-dpdk和qemu之间vhost-user通信，guest和ovs-dpdk之间通过virtio descriptor共享内存，数据到了ovs-dpdk，ovs-dpdk软件处理然后从一个硬件网卡出去。
基于这种方案做offload最自然，ovs-dpdk收到报文不再查转发规则做操作，而是把virtio descriptor转换成厂商vf的descriptor，然后就交给硬件，硬件查转发规则做转发。
这种方案ofed包中ovs实现了dpdkvdpa类型的接口，对应着一个vf和一个vf representor。
ovs-dpdk调用rte_flow，rte_flow再调用厂商pmd driver下转发规则。
总结
如果基于mellanox CX5做offload就只能用ovs-dpdk了。
