内核传输队列长度（txqueuelen）是协议栈向网卡驱动提交数据包的排队上限，单位为包，固定不变，决定丢包阈值；可用ip link show eth0查txqlen字段或cat /sys/class/net/eth0/tx_queue_len直接读取。
用 ip link show 查内核传输队列长度（txqueuelen）
这个值是内核协议栈向网卡驱动提交数据包时的排队上限，单位是“包”，不是字节。它不随流量变化，只决定丢包阈值。
-
ip link show eth0输出中找txqlen <n></n>字段，比如txqlen 1000 - 等价但更轻量的方式：
cat /sys/class/net/eth0/tx_queue_len，直接读文件，无解析开销 - 如果网卡是 DOWN 状态，
ip link show默认不显示该接口；加dev eth0仍能查到，但需确保接口名存在 - 回环接口
lo的txqueuelen通常是 1，调它没实际意义
用 ethtool -g 查网卡硬件 Ring Buffer 深度
这是网卡芯片内部 DMA 缓冲区大小，直接影响收发包是否在硬件层丢包。和 txqueuelen 完全无关，但协同影响整体丢包行为。
-
ethtool -g eth0输出里看Current hardware settings下的RX和TX值，例如RX: 2048 - 若显示
No data available，说明驱动不支持调整（常见于virtio_net等虚拟网卡） -
Pre-set maximums是硬件上限，硬设超限会报Operation not supported，比如 Intel 千兆卡上限常为 4096，Mellanox 卡可达 8192
别把 iostat -x 的 avgqu-sz 当成队列深度
avgqu-sz 是采样周期内 block layer 中等待+进行中的 I/O 请求均值，反映负载结果，不是配置上限。拿它当“当前队列长度”去调参，会误判瓶颈。
- 值为 0.8 不代表“还有空间”，可能只是 IO 模式稀疏；值为 25 也不等于“已满”，得对照设备理论最大值（NVMe 常是 64k，SATA SSD 多为 32）
- 持续 > 设备
queue_depth × 0.8才提示排队溢出；仅看数字高低没意义 -
await显著 >svctm时，avgqu-sz才有诊断价值——否则只是空闲波动
查 SCSI 或 NVMe 设备队列深度要用 lsscsi -l 或 /sys/block/xxx/device/queue_depth
这不是网络接口的队列，但名字带 “queue depth” 容易混淆。它控制主机向存储设备并发发多少 I/O，请勿和网卡参数混用。
-
lsscsi -l输出末尾的queue_depth=16就是当前值；对应内核路径是/sys/block/sda/device/queue_depth - NVMe 设备优先查
/sys/block/nvme0n1/device/queue_depth和/sys/block/nvme0n1/queue/nr_requests - 若
queue_depth文件不存在，说明由固件或内核硬编码决定，不可运行时修改
ethtool -g；TCP 重传陡增且 overruns 持续增长？才该查 txqueuelen；存储延迟高、%util 100% 但 IOPS 远低于标称值？才动 queue_depth。三者作用域、参数来源、修改方式都不同，强行统一处理只会让问题更难定位。
