NXP CPU 网卡性能优化的一次分析

硬件环境:

• NXP T1042（Power PC）  4Core 的CPU 
• CPU 内部的 MAC
• 千兆 PHY ：88E1512

内核版本：

• 4.9版本内核

测试方法：

使用 BigTao 220 网络流量测试仪测试，设备上跑一个数据转发程序 testrawsocket ，将eth0网卡收到的数据，从eth1发出去，将eth1收到的数据，从eth0发出去。基本上双向透传。然后流量仪分别以 不同的速度打流，观察丢包率。

测试前分析：

分析丢包原因 和 优化网卡性能是两个不同的问题，因为网卡丢包有很多种原因，硬件原因(时序 时钟 信号)？ MAC PHY驱动原因？中断原因？还是CPU原因处理不过来？要特别注意 CPU均衡 和 中断均衡 两个概念。

一般处理丢包问题的思路是这样的

ping 丢包吗 --> 小流量打流丢包吗 --> 大流量打流丢包吗  

确定是哪个阶段发生的丢包，可以根据打流时的丢包规律来推断，所以打流的时候速率尽量从 0 - 100 慢慢打流观察，看看丢包的规律是怎样的。而且打流的时候，一定要注意观察 CPU的占用率，中断的情况，看看性能的瓶颈是什么，丢包的原因是什么。 (观察CPU占用 情况，x% idle, 哪个核上跑，软中断)

由于网卡一旦协商成功，1000M ， 时钟速率都是固定的， 如果小流量不丢包，一般硬件的时序，什么的应该没问题。

初次打流测试，分析原因

NXP CPU 网卡会有4个QMan , 下面的命令是启用一个QMan , 默认是跑在CPU0

 # cat /proc/cmdline 
console=ttyS0,115200 root=/dev/ram rw usdpaa_mem=256M bportals=s0 qportals=s0

 # cat /proc/interrupts | grep QMan
122:         20          0          0          0   OpenPIC   122 Level     QMan portal 0

打流的结果如下： 

 可以看出来，速度越大，丢包越多。观察下 速度跑在29%时的CPU情况

打流速度在29% 时的 CPU0 已经跑满了，其它几个核都是空闲的。

可以看到所有的网卡中断都在0核处理的。

应用程序testrawsocket ，因为是单线程，默认掩码F, 按时间片轮回在4个核上运行。

也就是说，testrawsocket 也会在0核上跑，中断一直在0核上处理，

CPU0的负载真的是太TM大了，累死了要！而CPU1-3 闲的蛋疼！！

说明这是CPU 和中断 没有均衡。

第一次优化策略：启用4QMan, 中断 和 CPU均衡

启用4个QMan, 中断均衡到4个核，单线程程序无法CPU均衡，按时间片轮回在4个核上运行

去掉 参数 网卡绑核的参数，改用4个QMan，一个QMan 默认在一个核上

 # cat /proc/cmdline 
console=ttyS0,115200 root=/dev/ram rw

 # cat /proc/interrupts | grep QMan
116:          0          0          0         10   OpenPIC   116 Level     QMan portal 3
118:          0          0          9          0   OpenPIC   118 Level     QMan portal 2
120:          0          9          0          0   OpenPIC   120 Level     QMan portal 1
122:          9          0          0          0   OpenPIC   122 Level     QMan portal 0

去掉之后，跑28%，看下CPU 和 中断都是均衡的

 启用4个QMan, 而且4个核中断均衡后，发现性能从29%提升到 36%左右

 继续观察CPU的情况，下面两张图是速度跑到38% 的情况，

因为网卡转发的程序进程是单进程，默认掩码是F,

调度的时候是分别在4个核上单独跑一会儿，根据top可以看到

网卡转发程序 + 1/4的网卡中断，已经将单核跑满了。

第二次优化：网卡中断绑CPU3核，进程绑到CPU1核

注意：网卡的数据在一直变化，所以CACHE不命中对性能的影响不大，中断IRQ 和 程序不在一个核上，关系不大。

irqs=`cat /proc/interrupts |grep "QMan portal" | awk '{print $1}'`
for irq in $irqs;do
	irq=${irq%:*}
	echo 8 > /proc/irq/$irq/smp_affinity
done

taskset -p 2 `pidof testrawsocket`

应用程序在CPU1上跑，中断在CPU3上跑，下图是跑到47%的时候

 性能从 38%提升到 47%

第三次优化：去掉内核中无用debug信息

将内核的kernel hacking  能关闭的去掉，比如 debug信息，debugfs, 检测spinklock等功能

关闭cgroup  namespace cpu freq等功能

跑79.5%时：

优化后跑到 79.5%

第四次优化， testrawsocket 转发程序 优化

关于UDP丢包，除了系统因素以外，testrawsocket 程序设计也有很大的关系。

1、如果是CPU利用率是瓶颈，又是多核CPU，那么就需要改为多线程，分别跑在不同的核上来分担压力；或者 slect epoll 实现 减小cpu利用率

     ->代码待实现

2、要保证UDP接收缓冲区足够大， 否则这样缓存太小，不能及时接收数据会造成丢包。

由于UDP没有连接是不可靠的，较快的发送端可以很容易淹没较慢的接收端，导致接收端的UDP丢弃数据报。如果UDP包过大，或者UDP包发送的速率过快，突发大数据流量超过了缓冲区上限，就会造成丢包。UDP是没有流量控制的：UDP套接字的缓冲区是以一个个报文为单位进行排队的，调用一次recvfrom表示提取一个报文，和TCP基于字节流的方式是不同的。因此，如果socket接收缓存设置过小，就会因为UDP包过大或者发包速率过快而丢包。

调整UDP接收缓冲区有两种方法，一种是通过系统socket套接字接口，另一种是通过 修改内核的参数来实现。

重新设置系统缓冲区最大值，再调整UDP缓冲区大小：

/* setsockopt()函数修改：*/

//函数原型
int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

sockfd: 标识一个套接字的描述字
level:　选项定义的层次：支持SOL_SOCKET, IPPROTO_TCP, IPPROTO_IP,和IPPROTO_IPV6
optname：需设置得选项 SO_RCVBUF(接收缓冲区)，SO_SNDBUF(发送缓冲区)
optval：指针，指向存放选项待设置的新值的缓冲区
optlen：optval的大小

//示例
int recv_size = 2 * 1024 * 1024;    //设置为4M
setsockopt(s,SOL_SOCKET, SO_RCVBUF, (const char *)&recv_size,sizeof(recv_size));  

UDP接收缓冲区默认值：cat /proc/sys/net/core/rmem_default
本系统：212992 = 208K
UDP接收缓冲区最大值：cat /proc/sys/net/core/rmem_max，UDP最大可设置值的一半
本系统：212992 = 208K，即最大值425984 = 416K
UDP接收缓冲区最小值：sysctl -a | grep rmem

本系统：net.ipv4.udp_rmem_min = 4096 = 2K，由内核的宏决定
UDP发送缓冲区默认值：cat /proc/sys/net/core/wmem_default

本系统：212992 = 208K
UDP发送缓冲区最大值：cat /proc/sys/net/core/wmem_max
本系统：212992 = 208K，即最大值425984 = 416K
UDP发送缓冲区最小值：sysctl -a | grep wmem
本系统：net.ipv4.udp_wmem_min = 4096 = 2K，由内核的宏决定。

3、接收数据后 处理数据的过程太慢，也可能造成丢包。

4、优化 接收buffer , 改为多buffer 循环缓冲区，接收线程为 生产者，发送线程为消费者，也是0拷贝

----> 代码待实现， 此种优化，适合 CPU 资源有很大余量，性能瓶颈在  网卡收包速度大于网卡发包速度，因为收到数据包之后，很可能需要数据处理渲染，才能发出去。这样能最大限度的保证 发送线程不闲着，一直发送！