netdev_budget_usecs和netdev_budget是排查go视频转发卡顿、丢帧、高延迟的核心参数，前者控制napi单次轮询最大时间（默认2000µs，建议调至5000–10000），后者限制单次处理包数（默认300，需配合多队列调至600），二者须与net.core.netdev_max_backlog、rss绑核及ring buffer协同优化，否则易引发软中断堆积、skb丢弃和应用层饥饿。
netdev_budget_usecs 和 netdev_budget 是排查 Go 视频转发服务在 Linux 上卡顿、丢帧、高延迟的核心切入点——它们直接控制 NAPI 轮询的“时间片”与“包数上限”，而视频流（尤其是多路 RTMP/HLS 推流+转封装）极易触发软中断处理不及时、接收队列堆积、skb 丢弃等问题。
netdev_budget_usecs 设置过小导致轮询提前退出
Go 视频服务常依赖 epoll + read() 从 socket 拿包，但前提是内核已把网卡数据搬进协议栈。若 netdev_budget_usecs 太小（如默认 2000 µs），NAPI 在软中断中刚处理几毫秒就强制退出，大量数据仍滞留在网卡 Ring Buffer 或 softnet_data->input_pkt_queue，造成应用层读不到新包、缓冲区饥饿、视频卡顿。
- 默认值通常为
2000（µs），在万兆网卡 + 多路 4K 流场景下明显不足 - 实测建议从
5000起步，逐步加到10000（10ms），观察/proc/net/softnet_stat第 1 列（processed）与第 2 列（dropped）比值：若 dropped 持续上升，说明预算不够 - 临时调整：
sudo sysctl -w net.core.netdev_budget_usecs=10000 - 持久化写入：
echo "net.core.netdev_budget_usecs = 10000" >> /etc/sysctl.d/99-napi.conf
注意：netdev_budget_usecs 不是越大越好；超过 20ms 可能挤压其他 softirq（如 timer、block），反而引发调度抖动。
netdev_budget 与网卡多队列协同失效
Go 程序若绑定单个 CPU（如 taskset -c 3 ./video-forwarder），而网卡启用了 16 队列但未做 RSS 均衡，会导致大部分包被送到某几个 CPU 的 softnet_data，这些 CPU 的 NAPI 轮询压力远高于其他核。此时仅调大 netdev_budget（默认 300）可能加剧单核软中断饱和。
- 先确认队列分布：
cat /proc/interrupts | grep <nic>-tx</nic>，看 IRQ 是否集中在少数 CPU - 若是，用
ethtool -L <nic> combined 16</nic>并配合sudo bash -c 'echo 0-15 > /proc/irq/*/smp_affinity_list'均匀绑定（需按实际 CPU 数调整） - 再同步调高
netdev_budget：sudo sysctl -w net.core.netdev_budget=600 - 注意：该值必须是整数，且不能超过
net.core.netdev_max_backlog（否则无意义）
视频流场景下 Ring Buffer 与 net.core.netdev_max_backlog 必须匹配
Go 视频转发常使用零拷贝或 mmap 方式收包，但底层仍依赖内核 skb 分配。当突发流量（如关键帧 I-frame 批量到达）超过 net.core.netdev_max_backlog，内核会直接丢弃新包——这比应用层丢帧更隐蔽，日志里只显示 rx_queue_full。
- 查看当前值：
sysctl net.core.netdev_max_backlog（默认常为 1000） - 对于 10Gbps 网卡 + 8 路 1080p 流，建议设为
5000～10000 - 同时检查网卡 Ring Buffer：
ethtool -g <nic></nic>，RX 至少设为4096（ethtool -G <nic> rx 4096</nic>） - 若
netstat -s | grep "packet receive errors"中ring buffer overflow非零，说明 Ring Buffer 已溢出，优先调大它而非 backlog
Go 程序本身绕过内核队列的常见误操作
部分 Go 视频服务尝试用 AF_PACKET + SOCK_RAW 直通网卡，或启用 AF_XDP，但这要求驱动支持且配置严格。若未正确初始化 XDP 程序或 fallback 到 generic mode，反而因额外拷贝和锁竞争导致性能更差。
- 检查是否误启 XDP：
ip link show <nic> | grep xdp</nic>，非必要勿开 - 使用
AF_PACKET时务必设置SO_RCVBUF足够大（至少 4MB），否则内核 packet ring 自身就成瓶颈 - 更稳妥做法：保持标准 socket，专注优化内核协议栈路径，而非跳过它
真实瓶颈往往不在 Go 代码，而在内核收包路径上那几微秒的决策延迟——盯住 /proc/net/softnet<em>stat</em>、ethtool -S <nic></nic> 中的 rx.*_dropped 和 rx_missed_errors，比 profile Go 二进制更有价值。
