其他分享
首页 > 其他分享> > 中断均衡脚本

中断均衡脚本

作者：互联网

中断均衡脚本

 

来源 https://www.right.com.cn/forum/thread-4041282-1-1.html

基于OpenWrt 19.07分支，添加杂七杂八的补丁与设备支持，弄出的要求可靠性与性能的版本。
相比于OpenWrt原版，有以下区别：

相比于Lean，有以下区别：

同时，从lean和master中引入了ACRH17与R6800机型的配置文件。
会不定时同步OpenWrt 19.07的变动，19.07.x这种主版本肯定会更新。
代码地址：
https://github.com/presisco/openwrt/tree/openwrt-19.07

 

OpenWrt路由器多核终端均衡脚本 转发性能大幅提升50%

来源  https://www.right.com.cn/forum/thread-3191113-1-1.html

OpenWrt默认、Lean OpenWrt默认、使用irqbalance及转发优化版本的核心分配情况如下(IPQ40xx):

中断 OpenWrt Lean irqbalance 转发优化
网络队列rx CPU123 CPU0123 CPU123 CPU12交替
网络队列tx 交替 交替 交替 CPU12交替
网络中断rx CPU0123 4个一组交替 交替 4个一组CPU12反向交替
网络中断tx CPU0123 交替 交替 CPU12反向交替
无线ahb CPU0123 CPU2 CPU2 CPU3
无线pcie CPU0123 CPU3(设置无效) CPU0 CPU3
其他(usb,dma,gpio...) CPU0123 CPU0123 CPU0/CPU2/CPU3 CPU0



CPU123表示使用CPU1、CPU2、CPU3均可。为了提升局部性以提升缓存效率，中断往往被固定在所有指定CPU中最小的那个，在缺少硬件NAT与千兆网的情况下很容易占满1个CPU核心而其他核心空闲，出现性能瓶颈。因此需要调整中断与CPU的对应关系。。

使用两台间隔7米的ACRH17组建WDS无线桥接网络，主路由中运行iperf3服务器，主从路由通过QCA9984 5G进行连接，测试电脑连接于从路由的LAN1接口。
两台ACRH17均使用OpenWrt官方19.07.2固件与ath10k无线驱动。

不同中断绑定配置下的转发性能如下表所示：

中断绑定配置 速度/Mbps
OpenWrt默认 495
irqbalance 476
Lean固件默认策略 386
转发优化 581

我已经将中断的配置代码整合为脚本，只需要根据个人需求配置中断与CPU的对应关系，并上传到路由器中直接执行即可完成设定。每次重启路由器后脚本都需要重新执行。目前有基于OpenWrt/Lean与IPQ40xx系列SOC（4018/4019/4028/4029等）的脚本可直接使用。PandoraBox、AsusWrt、Merlin等及非IPQ40xx系列SOC的没有现成脚本。

中断均衡脚本：
中断均衡脚本链接

更新3-2020/3/11 10:00重写mt7621与bcm53xx的均衡脚本。
mt7621将CPU0/1处理eth0.1网络队列及USB/DMA，CPU2/3处理eth0.2网络队列及wifi。
bcm53xx使用CPU0/1处理网络队列，CPU0处理以太网，CPU1处理wifi、USB。

更新2-2020/3/10 22:30
重写ipq40xx的均衡脚本，将CPU1与CPU2用于处理网络端口队列，CPU8处理无线

更新1-2020/3/9 0:35
将ipq40xx.sh中网络相关irq全部指定至CPU2，与实验中相同。

 

1.早在3年前,上面说的平衡PandoraBox全都有了.
2.影响NAT最大的不是这个多核平衡,而是offload,就是我们常说的GSO/TSO,
垃圾BCM的4708/4709就是因为故意阉割了offload.所以NAT才会跟MT7621差不多.
3.当前IPQ4019上面的EDMA是支持大部分offload,除去CPU的平衡外,EDMA还支持16个硬件队列.这其实就已经是多核优化了,性能上不来还有很大原因是netfilter太多东西了.
4.假设OpenWrt能利用上IPQ806x的NSS协处理器,NAT性能会远超其他的设备.

 

R7800(IPQ8065)带硬件NSS驱动加速  实测1000M跑满的时候，CPU没有占用。

来源 https://www.right.com.cn/forum/thread-4130959-1-1.html

这个不错，但是集成的软件比较老了,所以我在他源码的基础上做了一些改进
使用的是官方19.07的源码和LEAN的一部分源码
OPENWRT官方源码:https://github.com/openwrt/openwrt
感谢大神LEAN：https://github.com/coolsnowwolf/lede
感谢大神quarky：https://forum.openwrt.org/t/ipq806x-nss-drivers/12613
感谢大神presisco：https://www.right.com.cn/forum/thread-4041282-1-1.html

 

IPQ806X NSS NAPI 驱动处理流程分析

IPQ806X网络子系统（NETWORK SUB SYSTEM，简称NSS）NAPI入口函数是：
int nss_core_handle_napi(struct napi_struct* napi,int budget)
其中，入参budget是每次消耗的预算，即一次最多处理几个报文。
在下面的循环中，会判断这个值是否已减到了0，非零时继续。
基本流程是：
1、napi->dev中记录有NSS的中断上下文信息，包含中断号。首先根据这个中断信息获取中断发生的原因码，一个32位整型值。
2、有两重循环，用代码描述是：
do{
while(中断原因码非0，预算非零)
{
处理DMA中的数据，上报到网络协议栈，计算本次处理数
减少预算
如果本次处理数小于权重值，清除原因码中相应已处理过的优先级位，避免淹死在某一个优先级中队列中
}
重新读取中断，更新原因码
}while(中断原因码非0，预算非零)

========= End

 

 

OpenWrt默认、Lean OpenWrt默认、使用irqbalance及转发优化版本的核心分配情况如下(IPQ40xx)：

中断OpenWrtLeanirqbalance转发优化
网络队列rx CPU123 CPU0123 CPU123 CPU12交替
网络队列tx 交替 交替 交替 CPU12交替
网络中断rx CPU0123 4个一组交替 交替 4个一组CPU12反向交替
网络中断tx CPU0123 交替 交替 CPU12反向交替
无线ahb CPU0123 CPU2 CPU2 CPU3
无线pcie CPU0123 CPU3(设置无效) CPU0 CPU3
其他(usb,dma,gpio...) CPU0123 CPU0123 CPU0/CPU2/CPU3 CPU0

CPU123表示使用CPU1、CPU2、CPU3均可。为了提升局部性以提升缓存效率，中断往往被固定在所有指定CPU中最小的那个，在缺少硬件NAT与千兆网的情况下很容易占满1个CPU核心而其他核心空闲，出现性能瓶颈。因此需要调整中断与CPU的对应关系。

结构

脚本参照init.d的格式编写，可直接复制到路由器的/etc/init.d目录下，调整文件名为set_smp_affinity（如果有同名文件则删除），每次重启后即可自动设置irq与核心的绑定关系。 CPU核心与Mask遮罩值的对应关系如下所示：

CPU0CPU1CPU2CPU3
1 2 4 8

如果需要同时使用多个核心，则直接将遮罩值累加取16进制，如使用CPU2与CPU3则值为C。 项目中脚本与平台的对应关系如下表所示：

脚本名称对应平台说明
ipq40xx/openwrt.sh 高通IPQ4018/4019/... 针对有线与无线转发优化的配置
ipq40xx/lean-default.sh 高通IPQ4018/4019/... Lean固件中的默认配置
mt7621/openwrt.sh 联发科mt7621 针对有线与无线转发优化的配置
mt7621/lean-default.sh 联发科mt7621 Lean固件中的默认配置
mt7621/pandorabox.sh 联发科mt7621 适用于潘多拉的有线无线优化配置
bcm53xx/openwrt.sh 博通bcm4708/4709 针对有线与无线转发优化的配置

状态

目前只基于Asus RT-ACRH17测试了IPQ4019平台。

测试场景

使用两台间隔7米的ACRH17组建WDS无线桥接网络，主路由中运行iperf3服务器，主从路由通过QCA9984 5G进行连接，测试电脑连接于从路由的LAN1接口。 两台ACRH17均使用OpenWrt官方19.07.2固件与ath10k无线驱动。 测试电脑中运行代码iperf3 -c 主路由IP -t 30 -P 4。 使用从路由测试均衡脚本。 吞吐量的结果如下表所示：

中断绑定配置速度/Mbps
OpenWrt默认 495
Lean默认 386
irqbalance 476
转发优化 581

标签：脚本,中断,CPU0123,CPU2,CPU3,交替,均衡,OpenWrt
来源： https://www.cnblogs.com/lsgxeva/p/16414863.html