net.core.dev_weight 控制单次 net_rx_action 轮询最多处理的网络包数，默认300，影响高吞吐下软中断处理效率；需结合 RSS/RPS、netdev_max_backlog 等协同调优。
net.core.dev_weight 控制的是内核 NAPI 轮询机制中，单次 net_rx_action 循环最多处理的网络包数量（即 per-CPU softirq 的 budget）。它不叫 dev_weight_rx，正确参数名是 net.core.dev_weight——这是影响高吞吐下接收路径效率的关键软中断配额参数。
它到底管什么？
- 每个 CPU 上的
softnet_data结构维护一个待轮询的 NAPI 实例队列； -
net_rx_action()函数每次被触发时，会按顺序调用各 NAPI poll 函数，直到耗尽budget（即dev_weight值）或队列清空； - 默认值是 64（老内核）或 300（较新内核，如 5.10+），对 10G+ 小包流量明显不够，容易造成 backlog 积压、
RcvbufErrors上升、甚至丢包； - 它和
netdev_max_backlog协同工作：前者决定“一次能处理多少”，后者决定“最多能缓多少没来得及处理的包”。
怎么判断需要调大？
看这两个信号是否同时出现：
-
top或htop中si（softirq）CPU 使用率持续 >30%； -
/proc/net/snmp中TcpExt: RcvbufErrors（内核 ≥5.10）或老内核中UdpInErrors/ListenOverflows异常增长； -
ethtool -S eth0 | grep rx_packets显示网卡收包数远高于netstat -s | grep "segments received"—— 差值变大说明包卡在驱动层未进协议栈。
✅ 注意：只看到
TCPBacklogDrop是 socket 层满（sk_receive_queue），和dev_weight无关；真正对应的是RcvbufErrors或软中断延迟。
推荐调优值与设置方法
合理取值范围
- 普通万兆网卡（小包为主）：256–512
- 高密度低延迟场景（如金融行情、DPDK混合部署）：512–1024
- 不建议超过 1024：过大会延长单次 softirq 执行时间，增加调度延迟，反而影响实时性。
设置方式
# 临时生效（重启丢失） sudo sysctl -w net.core.dev_weight=512 # 永久生效 echo "net.core.dev_weight = 512" | sudo tee -a /etc/sysctl.conf sudo sysctl -p
必须同步检查的配套配置
单独改 dev_weight 效果有限，需确保底层数据通路不堵：
✅ RSS / RPS 开启且均衡
ethtool -l eth0确认 RX 队列数 ≥ 逻辑 CPU 数；若用 RPS，检查/sys/class/net/eth0/queues/rx-*/rps_cpus是否覆盖所有 CPU。✅ NAPI poll 函数响应及时
驱动需支持 NAPI（现代主流网卡都支持），避免硬中断频繁触发；可用cat /proc/interrupts | grep eth0观察 IRQ 分布是否倾斜。✅
netdev_max_backlog匹配提升
若dev_weight提到 512，netdev_max_backlog建议同步设为 2000–5000（避免轮询还没开始，backlog 就溢出）。✅ 关闭 IRQ balance 干扰（可选）
sudo systemctl stop irqbalance，改用手动绑核（如echo 1 > /proc/irq/*/smp_affinity_list），防止 softirq 被频繁迁移到不同 CPU。
验证调优是否有效
-
改完后运行：
watch -n1 'grep -i "rcvbuferrors\|tcpbacklogdrop" /proc/net/snmp; echo; cat /proc/net/softnet_stat | head -5 | awk "{print \$1,\$2}"'关注第一列（processed）和第二列（dropped）的变化趋势：dropped 停止增长 + processed 单次更高，说明轮询更充分。
同时观察
si%是否下降、应用层吞吐是否提升（如 iperf3 测小包 pps）、延迟毛刺是否减少。
不复杂但容易忽略。
