异数OS TCP协议栈测试--网卡适配

异数OS TCP协议栈测试--网卡适配

为了实际走向应用，异数OS目前适配了netmap平台，DPDK平台，暂时每端口单核单队列的模式，后面各项问题解决后，开始适配RSS FDIR方案，下面是目前适配各个网卡驱动平台的测试结果。

测试说明

测试硬件平台

CPU ： E5 2670 V1 2.3G
内存：64G
网卡： intel 82599 双口，5GT PCI E限制（损失30%满载收发包性能）

测试用例

1.双口双核，将网卡两个口用光纤回环链接，CPU3 创建TCP server,CPU 5创建 指定连接数量的TCP Client线程（每链接4线程），测试方案使用 异数OS TCP协议栈测试（三）–长连接篇的的测试方法，成绩是ECHO的iops成绩。

1.单口单核，将网卡1个口的TX RX光纤回环链接，CPU3 创建TCP server,同时创建 指定连接数量的TCP Client线程，测试方案使用 异数OS TCP协议栈测试（三）–长连接篇的的测试方法，成绩是ECHO的iops成绩。

3.UDP NIC回环，分别在双口双核 单口单核模式下，创建两个线程，两个线程绑定对应的网卡适配器，对发UDP包记录下收发包的速度，成绩是收包发包循环的次数，一次收一个发把一个包。

测试结果

网卡接口平台	测试用例	NIC UDP 回环	1链接	8TCP链接	32TCP链接	64TCP链接	128TCP链接	256TCP链接	600WTCP链接
dpdk	双口双核	10M	136K	1.037M	3.47M	4.06M	4.2M	4.4M	3.1M 会丢包丢链接
dpdk	单口单核	9M	136K	1.018M	2.35M	2.5M	1.95M	1.9M	950k
netmap	双口双核	8M	131K	940k	3.6M	4.2M	4.5M	4.7M	2.3M
netmap	单口单核	6M	131K	940k	2.2M	2.8M	2.7M	2.4M	1.5M
异数OS软件交换机	双口双核	13M	1.8M	4.6M	4.6M	4.6M	4.7M	4.8M	3.3M
异数OS软件交换机	单口单核	14M	5.3M	5.0M	5.0M	4.95M	4.95M	5.03M	4.3M

适配总结

netmap，dpdk，异数OS软件交换机测试对比

通过适配netmap和DPDK平台，总结一些问题，netmap适配下来，性能比DPDK要强大概10%到100%，尤其是在链接多，app业务占用内存多的环境，dpdk在3W链接以上会出现Server端RX丢包(Dropped)，导致链接大量的丢失，600W丢失500w，并造成不稳定，而这一现象目前在netmap环境下没有出现，netmap以及异数OS软件交换机可以做到600W 0丢包，另外netmap由于采用ring与上层协议栈交换数据，不需要分配释放包缓存，因此降低了适配复杂度，并提高了包交换性能，这使得netmap的性能可以达到异数OS软件交换机性能的90%，而DPDK只能交换包数组，需要大量的工作做包缓存管理，效率较低，这可能是DPDK实际上比netmap以及异数OS软件交换机慢的原因。

TCP协议栈适配网卡的问题

由于TCP需要类似ECHO的传输流程控制机制，因此单个链接并不能批量收发包，这导致使用批量收发包技术的网卡出现性能损失，性能被网卡约束所影响，出现了一个性能墙，由测试数据来看，必须在32或者64路以上并发TCP链接，才有希望利用10G网卡的IO能力，由于异数OS软件交换机使用内存交换技术（多核采用CPU cache跨核交换），因此延迟比较低，一般在70ns左右，因此不存在单链接性能墙的问题。

DPDK丢包问题分析

DPDK经过反复分析调参,任然无法解决丢包的问题，在3W链接以下以及UDP收发包测试中，DPDK可以0丢包，推断可能是需要设置网卡流控，但实际上设置后并没有任何效果，排除流控的问题，无奈用异数OS做了软件流控，将TCP客户端发包能力控制在5000以内,发现丢包问题任然无法解决，而异数OS此时对rte_eth_rx_burst的polling速度是30M，所以排除是协议栈延迟高的问题，经过慢速持续增长的链接线程观察（每秒创建1000个TCPClient，netmap平台可每秒创建200W链接无问题）,在Client链接线程数创建超过3W时，丢包现象开始发生，此时软件层占用巨页内存20M，正好达到E52670 L3 Cache的尺寸，所以暂时推断DPDK的ddio的ring polling技术可能存在问题，当l3 cache不足，需要在内存交换包时可能出现丢包。