测试环境：网络节点运行在Intel(R) Xeon(R) CPU E5-2630 v3服务器上，网卡使用intel的万兆卡82599ES
测试仪使用本人基于dpdk编写的程序，基本上可以打满万兆卡，小包的pps在1200w左右
于是我用测试仪给openstack的虚拟机打流量，为了尽量模拟实际情况采用了200w条数据流，其中通过FIP访问虚拟机，主要想测试一下neutron网络节点的转发性能，在测试中只使用了一路numa节点，经过各种优化后，性能大约在200wpps左右，一路numa节点的cpu全部si占用率为100%，如下是使用perf top获取到的cpu被各个函数占用的情况。
15.97% [kernel] [k] ipt_do_table 8.29% [kernel] [k] ____nf_conntrack_find 6.80% [kernel] [k] fib_table_lookup 2.97% [kernel] [k] __netif_receive_skb_core 2.73% [kernel] [k] _raw_spin_lock 2.72% [kernel] [k] nf_iterate 2.23% [kernel] [k] intel_crc4_2_hash2 2.12% [kernel] [k] masked_flow_lookup 2.03% [kernel] [k] nf_nat_ipv4_fn 1.83% [kernel] [k] check_leaf.isra.7 1.82% [kernel] [k] ovs_flow_mask_key 1.66% [kernel] [k] ip_finish_output 1.47% [kernel] [k] ixgbe_clean_rx_irq 1.43% [kernel] [k] ixgbe_xmit_frame_ring
考虑到已经将nf_conntrack优化到足够的快，基本上没有tuning的空间；于是我进行了第二组测试。在linux 内核协议栈中实现了一个快速的NAT方式，方法基本与nf_conntrack一样，只是不像nf_conntrack那么通用，路径那么长，锁的粒度也要比nf_conntrack小，粒度精细到哈希表中的元素，哈希算法和nf_conntrack一样。
得到的结果是230wpps，此时ovs的查询函数在iperf中显示占用了最多的cpu使用，大约在9%左右，推断出此时ovs是整个性能的瓶颈。
经过了两次对比可以看出在neutron CVR情况下，nf_conntrack和ovs流表对cpu的占用率大约在六四开。
因此估计在Intel(R) Xeon(R) CPU E5-2630 v3服务器上，两路numa节点全部使用的话，NEUTRON转发的
性能极限应该不会超过400wpps，因为性能并不会随着cpu的增加而线性的增加，随着cpu数目的增加，cpu对总线的竞争也越来越激烈，对内核的全局变量竞争也越来越激烈。
考虑到linux内核协议做NAT的路径比较长，而且nf_conntrack过于通用导致其性能不高;CVR的方式除了同网段的
虚拟机流量不走网络节点，其余全部要走网络节点；DVR的实现方式极其麻烦而且性能会更差（通过了两次的netns）
可以考虑在ovs中做NAT来提高性能，但是根据第二组测试的结果，分析其性能极限也就是在500wpps~600wpps左右
要想达到商业级的pps（1000wpps左右），以及dpdk ivshmem/vhost_user对虚拟机的性能加速，最终使用nfv+dpdk或许可以实现