先说结果： 通过 internal port 连接到 OVS 比通过 veth-pair 获得（ 略微 ）更好的性能。
测试结果1
我通过 iperf 工具在我的环境（一台物理机 2 个虚拟机）中以这种方式测试了性能： ovs-internal-port 11.1-11.4Gb/s (1 process) 12.9-13.3Gb/s (4 process)
veth-pair-device 10.8-11.0Gb/s (1 process) 11.8-12.2Gb/s (4 process)
测试结果2
系统是一台 PowerEdge R730，配备英特尔（R） 至强（R） CPU E5-2690 v3 @ 2.60GHz，运行 Linux 内核 4.0 。
以下是每轮 netperf 测试的 5 轮结果。单位为 Mbits/s。
原理分析
有一些一些关于最适合使用哪个接口来连接 Linux 容器或网络命名空间的讨论。有人说 Open vSwitch Internal port 是最好的，因为它的吞吐量。
嗯，如果你看一下 openvswitch 内核源，内部端口实际上是一个用 vport 备份的 netdev 设备。因此，当它被移动到另一个命名空间时，与 vswitch 的链接仍然存在，因为 vport 保留了引用。因此，这非常简单，从命名空间发送的数据包会通过与任何其他设备相同的代码路径，直到到达驱动程序层，该层的路径直接更改为 Open vSwitch 数据路径 （OVS DP）。
现在查看 veth 代码，数据包不会遵循相同的路径，因为默认情况下，veth 有一个 长度为 1000 个数据包的队列。因此，数据包被推送到该队列中，队列规则将运行。此外，使用多个 CPU 同时传输并不能很好地扩展，因为 veth 只有一个队列，因此该队列上会出现锁定争用。
此时，veth 数据包到达与 OVS 内部端口相同的点，但出于安全原因 ，它们不是直接进入 OVS DP ，而是被清理，然后转发 到另一个对等 netdev 设备。在这里，它与从硬件接收的任何其他 netdev 设备一样，因此它将传递 RPS（接收数据包转向）代码来选择目标 CPU（如果启用），然后将数据包推送到 CPU 的积压工作中并安排软中断 运行。 通常， 软中断在此代码路径返回处理队列后立即运行。
这意味着数据包会进入网络堆栈的初始部分 ，在该部分选择了适当的处理程序 - Bridges、Bonding、VLANs、Protocols 等。 由于数据包来自 OVS 端口，因此会调用 OVS DP 处理程序，从现在开始，内部端口和 veth 共享相同的代码路径。 将数据包推送到 CPU 的 backlog 中，然后等待软中断运行的额外开销当然会带来性能损失，但它实际上保证了系统的公平性。
使用场景对比：
- 在 openstack 的虚拟机、virtual router/network/loadbalancer 的网络命名空间设计中，都是使用internal port 连接到 ovs 网桥
- 但在所有 pod（容器）场景，不管是 ovs 还是 linux bridge 都是使用 veth-pair，因为需要处理 ovs internal port 和 容器 eth0（k8s 会检测）的命名上的问题
结论：如果不是容器场景，最好还是直接使用 internal port
参考： github.com/antrea-io/a... arthurchiao.art/blog/ovs-de... flavioleitner.blogspot.com/