DPDK是X86平台报文快速处理的库和驱动的集合，不是网络协议栈，不提供二层，三层转发功能，不具备防火墙ACL功能，但通过DPDK可以轻松的开发出上述功能。
DPDK的优势在于，可以将用户态的数据，不经过内核直接转发到网卡，实现加速目的。主要架构如图所示：
传统的socket方式与DPDK对比：
DPDK关键技术点：
OpenvSwitch 以其丰富的功能，作为多层虚拟交换机，已经广泛应用于云环境中。Open vSwitch的主要功能是为物理机上的VM提供二层网络接入，和云环境中的其它物理交换机并行工作在Layer 2。
传统host ovs工作在内核态，与guest virtio的数据传输需要多次内核态和用户态的数据切换, 带来性能瓶颈.
Ovs+Dpdk和Ovs本身之间的区别可以由下图简单来表示：
在早期OVS的版本中，为缓解多级流表查表慢的问题，OVS在内核态采用Microflow Cache方法。Microflow Cache是基于Hash的精确匹配查表（O(1)），表项缓存了多级查表的结果，维护的是每条链接粒度的状态。Microflow Cache减少了报文进用户态查多级表的次数。一条流的首报文进入用户态查表后，后续的报文都会命中内核中的Microflow Cache，加快了查表速度。但是对于大量短流的网络环境来说，Microflow Cache命中率很低，导致大部分报文仍然需要到用户态进行多级流表查找，因此转发性能提升有限。
而后，为了解决Mircoflow Cache存在的问题，OVS采用Megaflow Cache代替了Mircoflow Cache。与Mircoflow Cache的精确Hash查表不同，Megaflow Cache支持带通配的查表，所以可减少报文至用户空间查表的次数。庾志辉的博客中当时分析的就是关于megaflow的数据结构和查表流程，相关内容不在此赘述，请看上文中的链接。但是，由于OVS采用元组空间搜索（下文介绍）实现Megaflow Cache的查找，所以平均查表次数为元组表的数量的一半。假设元组空间搜索的元组表链为m，那么平均查表开销为O(m/2)。Mircoflow Cache和Megaflow Cache查表开销对比为O(1)< O(m/2)。因此，Megaflow Cache相比于Mircoflow Cache，尽管减少了报文进用户空间查表的次数，但是增加了报文在内核态查表的次数。
为此，OVS当前版本采用Megaflow Cache+Microflow Cache的流Cache组织形式，仍保留了Microflow Cache作为一级Cache，即报文进入后首先查这一级Cache。只不过这个Microflow Cache含义与原来的Microflow Cache不同。原来的Microflow Cache是一个实际存在的精确Hash表，但是最新版本中的Microflow Cache不是一个表，而是一个索引值，指向的是最近一次查Megaflow Cache表项。那么报文的首次查表就不需要进行线性地链式搜索，可直接对应到其中一张Megaflow的元组表。这三个阶段的查表开销如表所示。
DPDK 高性能(user space) 网卡驱动、大页内存、无锁化结构设计，可以轻易实现万兆网卡线速的性能。ovs-dpdk使vm到vm和nic到vm的整个数据传输都工作在用户态，极大的提升了ovs的性能。
另外，ovs-dpdk 结合了DPDK和vhost-user技术的优势。vhost-user是一个用户态的vhost-backend程序，从虚拟机到host上实现了数据零拷贝(zero copy)。
（1）原生ovs数据流处理过程如下：
（2）ovs-dpdk方式：
用户态进程直接接管网卡收发数据，采用“IO独占核”技术，即每个端口分配一个核专门用于数据收发，轮询式处理方式代替中断式处理，显著提高IO性能。
总结：
| 比较 | 原生ovs | ovs-dpdk |
|---|---|---|
| host收发包 | 通过host的linux内核访问网卡 | 通过dpdk高速数据通道收发包 |
| 内部交换 | 在内核态datapath进行交换 | 基于ovs，提供dpdk datapath的交换能力 |
| vm后端驱动 | 使用vni，基于开源tap进行优化 | vhost-user |
| vm前端驱动 | 标准virtio设备 | 标准virtio设备 |
| 交换路径 | 2个线程：物理网卡(中断机制)->转发线程->放到tap设备队列->vhost_net取包送给vcpu | 1个线程：物理网卡(DPDK DPM)->转发线程->送给vcpu |
硬件要求
网卡得支持DPDK，见：http://dpdk.org/doc/nics
CPU得支持DPDK, 测试命令：cat /proc/cpuinfo |grep pdpe1gb
不一定非要支持DPDK硬件的网卡，因为DPDK也支持virtio dpdk driver.
打开大页支持
hua@node1:~$ cat /etc/default/grub |grep GRUB_CMDLINE_LINUX
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on pci=assign-busses"
GRUB_CMDLINE_LINUX="transparent_hugepage=never hugepagesz=2M hugepages=64 default_hugepagesz=2M"
hua@node1:~$ mkdir /mnt/huge
hua@node1:~$ mount -t hugetlbfs nodev /mnt/huge
hua@node1:~$ echo 8192 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
hua@node1:~$ cat /proc/meminfo |grep HugePages_
HugePages_Total: 8192
HugePages_Free: 8192
HugePages_Rsvd: 0
HugePages_Surp: 0
hua@node1:~$ grep Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB配置网卡使用uio_pci_generic驱动, 虚机可以使用PF去做DPDK port，也可以直通方式使用VF：
至于PF的驱动，可以使用ixgbe，也可以使用DPDK PF driver；对于VF的驱动，可以使用ixgbefv，也可以使用DPDK VF driver. 如果要使用DPDK PF driver需在grub中加上iommu=pt.
如下方式也可以通信：
测试场景搭建
sudo ovs-vsctl ovsbr0 br-int
sudo ovs-vsctl set bridge ovsbr0 datapath_type=netdev
sudo ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk #Port name shoud begin with dpdk
# 给虚机创建普通ovs port:
sudo ovs-vsctl add-port ovsbr0 intP1 -- set Interface intP1 type=internal
sudo ip addr add 192.168.10.129/24 dev intP1
sudo ip link set dev intP1 up
sudo tcpdump -i intP1
# 或给虚机创建vhost-user port:
sudo ovs-vsctl add-port ovsbr0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser
# 虚机使用vhost-user port
sudo qemu-system-x86_64 -enable-kvm -m 128 -smp 2 \
-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1 \
-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-device virtio-net-pci,netdev=mynet1,mac=52:54:00:02:d9:01 \
-object memory-backend-file,id=mem,size=128M,mem-path=/mnt/huge,share=on \
-numa node,memdev=mem -mem-prealloc \
-net user,hostfwd=tcp::10021-:22 -net nic \
/bak/images/openstack_demo.img
# Inside VM:
sudo ifconfig eth0 192.168.9.108/24使用vhost-user方式示意图如下：
dpdk-virtio-net
