Neutron网络性能测试与分析（一） CVR

测试环境：网络节点运行在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或许可以实现

转载于:https://www.cnblogs.com/scottieyuyang/p/5665670.html