硬件环境:

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;doirq=${irq%:*}echo 8 > /proc/irq/$irq/smp_affinity
donetaskset -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 资源有很大余量，性能瓶颈在网卡收包速度大于网卡发包速度，因为收到数据包之后，很可能需要数据处理渲染，才能发出去。这样能最大限度的保证发送线程不闲着，一直发送！

NXP CPU 网卡性能优化的一次分析相关推荐

JVM性能优化之GC日志分析
JVM性能优化之GC日志分析文章目录 JVM性能优化之GC日志分析前言一.GC日志参数 GC日志参数常用的垃圾收集器配置大对象回收二.GC日志分析工具 GCeasy JVM memory ...
字节跳动Android三面视频解析：framework+MVP架构+HashMap原理+性能优化+Flutter+源码分析等
前言对于字节跳动的二面三面而言,Framework+MVP架构+HashMap原理+性能优化+Flutter+源码分析等问题都成高频问点!然而很多的朋友在面试时却答不上或者答不全!今天在这分享下这些 ...
《深入浅出DPDK》读书笔记（八）：网卡性能优化（异步中断模式、轮询模式、混和中断轮询模式）
本文内容为读书笔记,摘自<深入浅出DPDK> 82.DPDK的轮询模式 <DPDK PMD( Poll Mode Driver)轮询模式驱动程序> DPDK采用了轮询或者轮询混 ...
FT2000+下40G网卡性能优化
1.背景介绍目前在调试FT2000+模块时,遇到了40G网卡(mellanox CX5)性能问题,使用iperf测试时发现网卡性能只能达到11Gbps左右,远低于E5V4下面的36Gbps.FT20 ...
【ethtool】ethtool 网卡诊断、调整工具、网卡性能优化| 解决丢包严重
目录即看即用详细信息软件简介安装 ethtool的使用输出详解其他指令将 ethtool 设置永久保存如何使用 ethtool 优化 Linux 虚拟机网卡性能 ethtool 解决网 ...
linux 调整内核空间占用cpu,[Linux性能优化]3.CPU使用率100%,怎么办?
8种机械键盘轴体对比本人程序员,要买一个写代码的键盘,请问红轴和茶轴怎么选? CPU使用率是单位时间内CPU使用情况的统计,以百分比的方式展示. CPU时间是Linux通过事先定义的节拍率(内核中表 ...
mysql_性能优化一(慢查询分析)
4.1 总论 MySQL 性能优化其实是个很大的课题,在优化上存在着一个调优金字塔的说法: 很明显从图上可以看出,越往上走,难度越来越高,收益却是越来越小的. 比如硬件和 OS 调优,需要对硬件和 O ...
性能优化之思路和分析
.优化思路尽可能减少首屏必须资源的体积尽可能提前首屏必须资源/接口的请求发起时机延后+闲时预缓存非必要资源/请求代码分离 https://webpack.docschina.org/guide ...
Android性能优化一绘制原理分析
Android应用启动慢,使用时经常卡顿,是非常影响用户体验的,应该尽量避免出现. 1.卡顿的分类按照场景分可以分为: UI绘制绘制刷新应用启动安装启动冷启动热启动页面跳转页面间切换 ...

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

硬件环境:

内核版本：

测试方法：

测试前分析：

初次打流测试，分析原因

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

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

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

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

NXP CPU 网卡性能优化的一次分析相关推荐

最新文章

热门文章

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

硬件环境:

内核版本：

测试方法：

测试前分析：

初次打流测试，分析原因

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

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

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

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

NXP CPU 网卡性能优化的一次分析相关推荐

最新文章

热门文章

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

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