确认 Ring Buffer 满导致丢包需看三类证据：rx_missed_errors 持续上涨（驱动取空描述符）、rx_fifo_errors 非零（FIFO 未进缓冲区即丢）、ifconfig eth0 中 RX overruns 上升；rx_dropped 上涨则多属内核层问题，与 Ring Buffer 无关。
怎么确认是 Ring Buffer 满导致丢包
别急着调参数，先看证据。真正由 Ring Buffer 溢出引发的丢包，会在网卡硬件层静默丢弃，不进内核协议栈，所以 netstat -s 或 ss -s 看不到对应计数，但 ethtool -S 会明确报出来。
-
rx_missed_errors持续上涨 → 驱动来不及取包，Ring Buffer 描述符耗尽，典型“取空后还写” -
rx_fifo_errors非零 → 数据还没进 Ring Buffer，就在网卡内部 FIFO 被丢，说明接收路径前端已堵死 -
ifconfig eth0输出中RX overruns值上升 → 和rx_fifo_errors强相关，是 Ring Buffer 不足最直观信号 - 注意：
rx_dropped上涨 ≠ Ring Buffer 问题，它更常反映内核内存分配失败或 softirq 处理不过来
怎么查当前 Ring Buffer 大小和硬件上限
ethtool -g eth0 是唯一可靠方式，ip -s link 或 /proc/net/dev 完全不暴露这个值。
- 输出里
Current hardware settings下的RX值，就是当前生效大小（例如RX: 256） -
Pre-set maximums下的RX值，才是驱动允许的最大值（如RX: 4096），不能超 - 某些虚拟网卡（
veth、virtio_net）执行会报Operation not supported，说明根本不支持动态调整 - ixgbe 驱动默认 512，igb 默认 256，而 X710 卡固件版本不同，最大值可能卡在 2048 而非标称的 4096
怎么安全调大 RX Ring Buffer 并验证效果
调大不是越大越好，要阶梯式验证，避免引入新瓶颈。
- 必须用
root权限执行：ethtool -G eth0 rx 2048，普通用户报Operation not permitted - 调完立刻用
ethtool -g eth0确认Current值已更新，否则命令静默失败 - 同步检查软中断压力：
cat /proc/interrupts | grep eth0，若某 CPU 核上数值暴涨，说明单核处理不过来，需配RPS或调整 IRQ affinity - 联动调大内核参数：
net.core.netdev_max_backlog建议 ≥ Ring Buffer 大小，否则 softnet 队列成新瓶颈 - 验证是否真解决问题：用
watch -n1 'ethtool -S eth0 | grep -E "rx_missed|rx_fifo"'观察计数器是否停止增长
为什么调了还是丢包？常见被忽略的断点
Ring Buffer 只管“网卡到内核”的第一跳，后面还有两道关卡容易被当成它的锅。
-
netstat -s | grep UdpOverflows在涨 → 说明 UDP 套接字接收队列满，和 Ring Buffer 无关，该调net.core.rmem_max或应用层setsockopt(..., SO_RCVBUF, ...) -
/proc/net/softnet_stat第二列（dropped）持续增加 → 包进了 Ring Buffer，但 softirq 没处理完就被 softnet 队列丢弃，需查 CPU 负载和 RPS 配置 - 开了
tc qdisc netem或 iptables 限速规则 → 这类丢包完全不体现在ethtool -S里，得用tc -s qdisc show dev eth0单独排查 - 驱动太老或内核版本低 → 某些驱动对 >2048 的 Ring Buffer 支持不稳，升级 kernel 或固件前别硬刚上限
环形缓冲区满只是丢包链路上最靠前的一环，越往后的问题越难定位——比如 softnet dropped 上升时，你得同时盯 CPU、中断分布、内核日志，而不是再翻 ethtool。
