硬件环境:
- 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 资源有很大余量，性能瓶颈在? 网卡收包速度大于网卡发包速度，因为收到数据包之后，很可能需要数据处理渲染，才能发出去。这样能最大限度的保证 发送线程不闲着，一直发送！