老铁&＃xff0c;请关注一波

原文链接&＃xff1a;https://wsgzao.github.io/post/ethtool/

前言

之前记录过处理因为 LVS 网卡流量负载过高导致软中断发生丢包的问题&＃xff0c;RPS 和 RFS 网卡多队列性能调优实践[1]&＃xff0c;对一般人来说压力不大的情况下其实碰见的概率并不高。这次想分享的话题是比较常见服务器网卡丢包现象排查思路&＃xff0c;如果你是想了解点对点的丢包解决思路涉及面可能就比较广&＃xff0c;不妨先参考之前的文章 如何使用 MTR 诊断网络问题[2]&＃xff0c;对于 Linux 常用的网卡丢包分析工具自然是 ethtool。

ethtool 用于查看和修改网络设备(尤其是有线以太网设备)的驱动参数和硬件设置。你可以根据需要更改以太网卡的参数&＃xff0c;包括自动协商、速度、双工和局域网唤醒等参数。通过对以太网卡的配置&＃xff0c;你的计算机可以通过网络有效地进行通信。该工具提供了许多关于接驳到你的 Linux 系统的以太网设备的信息。

1. 了解接收数据包的流程

这里摘取了美团技术团队的分析&＃xff0c;在此表示感谢

接收数据包是一个复杂的过程&＃xff0c;涉及很多底层的技术细节&＃xff0c;但大致需要以下几个步骤&＃xff1a;

1. 网卡收到数据包。
2. 将数据包从网卡硬件缓存转移到服务器内存中。
3. 通知内核处理。
4. 经过 TCP/IP 协议逐层处理。
5. 应用程序通过 read() 从 socket buffer 读取数据。

将网卡收到的数据包转移到主机内存(NIC 与驱动交互)

NIC 在接收到数据包之后&＃xff0c;首先需要将数据同步到内核中&＃xff0c;这中间的桥梁是 rx ring buffer。它是由 NIC 和驱动程序共享的一片区域&＃xff0c;事实上&＃xff0c;rx ring buffer 存储的并不是实际的 packet 数据&＃xff0c;而是一个描述符&＃xff0c;这个描述符指向了它真正的存储地址&＃xff0c;具体流程如下&＃xff1a;

1. 驱动在内存中分配一片缓冲区用来接收数据包&＃xff0c;叫做 sk_buffer&＃xff1b;
2. 将上述缓冲区的地址和大小(即接收描述符)&＃xff0c;加入到 rx ring buffer。描述符中的缓冲区地址是 DMA 使用的物理地址&＃xff1b;
3. 驱动通知网卡有一个新的描述符&＃xff1b;
4. 网卡从 rx ring buffer 中取出描述符&＃xff0c;从而获知缓冲区的地址和大小&＃xff1b;
5. 网卡收到新的数据包&＃xff1b;
6. 网卡将新数据包通过 DMA 直接写到 sk_buffer 中。

当驱动处理速度跟不上网卡收包速度时&＃xff0c;驱动来不及分配缓冲区&＃xff0c;NIC 接收到的数据包无法及时写到 sk_buffer&＃xff0c;就会产生堆积&＃xff0c;当 NIC 内部缓冲区写满后&＃xff0c;就会丢弃部分数据&＃xff0c;引起丢包。这部分丢包为 rx_fifo_errors&＃xff0c;在 /proc/net/dev 中体现为 fifo 字段增长&＃xff0c;在 ifconfig 中体现为 overruns 指标增长。

通知系统内核处理(驱动与 Linux 内核交互)

这个时候&＃xff0c;数据包已经被转移到了 sk_buffer 中。前文提到&＃xff0c;这是驱动程序在内存中分配的一片缓冲区&＃xff0c;并且是通过 DMA 写入的&＃xff0c;这种方式不依赖 CPU 直接将数据写到了内存中&＃xff0c;意味着对内核来说&＃xff0c;其实并不知道已经有新数据到了内存中。那么如何让内核知道有新数据进来了呢&＃xff1f;答案就是中断&＃xff0c;通过中断告诉内核有新数据进来了&＃xff0c;并需要进行后续处理。

提到中断&＃xff0c;就涉及到硬中断和软中断&＃xff0c;首先需要简单了解一下它们的区别&＃xff1a;

• 硬中断&＃xff1a;由硬件自己生成&＃xff0c;具有随机性&＃xff0c;硬中断被 CPU 接收后&＃xff0c;触发执行中断处理程序。中断处理程序只会处理关键性的、短时间内可以处理完的工作&＃xff0c;剩余耗时较长工作&＃xff0c;会放到中断之后&＃xff0c;由软中断来完成。硬中断也被称为上半部分。
• 软中断&＃xff1a;由硬中断对应的中断处理程序生成&＃xff0c;往往是预先在代码里实现好的&＃xff0c;不具有随机性。(除此之外&＃xff0c;也有应用程序触发的软中断&＃xff0c;与本文讨论的网卡收包无关。)也被称为下半部分。

当 NIC 把数据包通过 DMA 复制到内核缓冲区 sk_buffer 后&＃xff0c;NIC 立即发起一个硬件中断。CPU 接收后&＃xff0c;首先进入上半部分&＃xff0c;网卡中断对应的中断处理程序是网卡驱动程序的一部分&＃xff0c;之后由它发起软中断&＃xff0c;进入下半部分&＃xff0c;开始消费 sk_buffer 中的数据&＃xff0c;交给内核协议栈处理。

通过中断&＃xff0c;能够快速及时地响应网卡数据请求&＃xff0c;但如果数据量大&＃xff0c;那么会产生大量中断请求&＃xff0c;CPU 大部分时间都忙于处理中断&＃xff0c;效率很低。为了解决这个问题&＃xff0c;现在的内核及驱动都采用一种叫 NAPI(new API)的方式进行数据处理&＃xff0c;其原理可以简单理解为 中断 &＃43; 轮询&＃xff0c;在数据量大时&＃xff0c;一次中断后通过轮询接收一定数量包再返回&＃xff0c;避免产生多次中断。

2. ifconfig 解释

[root&＃64;localhost ~]eth0: flags&＃61;4163 mtu 1500inet 192.168.1.135 netmask 255.255.255.0 broadcast 192.168.1.255inet6 fe80::20c:29ff:fe9b:52d3 prefixlen 64 scopeid 0x20ether 00:0c:29:9b:52:d3 txqueuelen 1000 (Ethernet)RX packets 833 bytes 61846 (60.3 KiB)RX errors 0 dropped 0 overruns 0 frame 0TX packets 122 bytes 9028 (8.8 KiB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

(1) RX errors

表示总的收包的错误数量&＃xff0c;这包括 too-long-frames 错误&＃xff0c;Ring Buffer 溢出错误&＃xff0c;crc 校验错误&＃xff0c;帧同步错误&＃xff0c;fifo overruns 以及 missed pkg 等等。

(2) RX dropped

表示数据包已经进入了 Ring Buffer&＃xff0c;但是由于内存不够等系统原因&＃xff0c;导致在拷贝到内存的过程中被丢弃。

(3) RX overruns

表示了 fifo 的 overruns&＃xff0c;这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的&＃xff0c;而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显&＃xff0c;overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了&＃xff0c;而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一&＃xff0c;上面那台有问题的机器就是因为 interruprs 分布的不均匀 (都压在 core0)&＃xff0c;没有做 affinity 而造成的丢包。

(4) RX frame

表示 misaligned 的 frames。

3. 网卡工作原理

如果上面接收数据包的流程觉得不够详细可以再看纯文字解释

网卡收包

网线上的 packet 首先被网卡获取&＃xff0c;网卡会检查 packet 的 CRC 校验&＃xff0c;保证完整性&＃xff0c;然后将 packet 头去掉&＃xff0c;得到 frame。网卡会检查 MAC 包内的目的 MAC 地址&＃xff0c;如果和本网卡的 MAC 地址不一样则丢弃 (混杂模式除外)。

网卡将 frame 拷贝到网卡内部的 FIFO 缓冲区&＃xff0c;触发硬件中断。(如有 ring buffer 的网卡&＃xff0c;好像 frame 可以先存在 ring buffer 里再触发软件中断(下篇文章将详细解释 Linux 中 frame 的走向)&＃xff0c;ring buffer 是网卡和驱动程序共享&＃xff0c;是设备里的内存&＃xff0c;但是对操作系统是可见的&＃xff0c;因为看到 linux 内核源码里网卡驱动程序是使用 kcalloc 来分配的空间&＃xff0c;所以 ring buffer 一般都有上限&＃xff0c;另外这个 ring buffer size&＃xff0c;表示的应该是能存储的 frame 的个数&＃xff0c;而不是字节大小。另外有些系统的 ethtool 命令 并不能改变 ring parameters 来设置 ring buffer 的大小&＃xff0c;暂时不知道为什么&＃xff0c;可能是驱动不支持。)

网卡驱动程序通过硬中断处理函数&＃xff0c;构建 sk_buff&＃xff0c;把 frame 从网卡 FIFO 拷贝到内存 skb 中&＃xff0c;接下来交给内核处理。(支持 napi 的网卡应该是直接放在 ring buffer&＃xff0c;不触发硬中断&＃xff0c;直接使用软中断&＃xff0c;拷贝 ring buffer 里的数据&＃xff0c;直接输送给上层处理&＃xff0c;每个网卡在一次软中断处理过程能处理 weight 个 frame)

过程中&＃xff0c;网卡芯片对 frame 进行了 MAC 过滤&＃xff0c;以减小系统负荷。(除了混杂模式)

网卡发包

网卡驱动程序将 IP 包添加 14 字节的 MAC 头&＃xff0c;构成 frame(暂无 CRC)。Frame(暂无 CRC)中含有发送端和接收端的 MAC 地址&＃xff0c;由于是驱动程序创建 MAC 头&＃xff0c;所以可以随便输入地址&＃xff0c;也可以进行主机伪装。

驱动程序将 frame(暂无 CRC)拷贝到网卡芯片内部的缓冲区&＃xff0c;由网卡处理。

网卡芯片将未完全完成的 frame(缺 CRC)再次封装为可以发送的 packet&＃xff0c;也就是添加头部同步信息和 CRC 校验&＃xff0c;然后丢到网线上&＃xff0c;就完成一个 IP 报的发送了&＃xff0c;所有接到网线上的网卡都可以看到该 packet。

网卡中断处理函数

产生中断的每个设备都有一个相应的中断处理程序&＃xff0c;是设备驱动程序的一部分。每个网卡都有一个中断处理程序&＃xff0c;用于通知网卡该中断已经被接收了&＃xff0c;以及把网卡缓冲区的数据包拷贝到内存中。

当网卡接收来自网络的数据包时&＃xff0c;需要通知内核数据包到了。网卡立即发出中断。内核通过执行网卡已注册的中断处理函数来做出应答。中断处理程序开始执行&＃xff0c;通知硬件&＃xff0c;拷贝最新的网络数据包到内存&＃xff0c;然后读取网卡更多的数据包。

这些都是重要、紧迫而又与硬件相关的工作。内核通常需要快速的拷贝网络数据包到系统内存&＃xff0c;因为网卡上接收网络数据包的缓存大小固定&＃xff0c;而且相比系统内存也要小得多。所以上述拷贝动作一旦被延迟&＃xff0c;必然造成网卡 FIFO 缓存溢出 - 进入的数据包占满了网卡的缓存&＃xff0c;后续的包只能被丢弃&＃xff0c;这也应该就是 ifconfig 里的 overrun 的来源。

当网络数据包被拷贝到系统内存后&＃xff0c;中断的任务算是完成了&＃xff0c;这时它把控制权交还给被系统中断前运行的程序。

缓冲区访问

网卡的内核缓冲区&＃xff0c;是在 PC 内存中&＃xff0c;由内核控制&＃xff0c;而网卡会有 FIFO 缓冲区&＃xff0c;或者 ring buffer&＃xff0c;这应该将两者区分开。FIFO 比较小&＃xff0c;里面有数据便会尽量将数据存在内核缓冲中。

网卡中的缓冲区既不属于内核空间&＃xff0c;也不属于用户空间。它属于硬件缓冲&＃xff0c;允许网卡与操作系统之间有个缓冲&＃xff1b;

内核缓冲区在内核空间&＃xff0c;在内存中&＃xff0c;用于内核程序&＃xff0c;做为读自或写往硬件的数据缓冲区&＃xff1b;

用户缓冲区在用户空间&＃xff0c;在内存中&＃xff0c;用于用户程序&＃xff0c;做为读自或写往硬件的数据缓冲区&＃xff1b;

另外&＃xff0c;为了加快数据的交互&＃xff0c;可以将内核缓冲区映射到用户空间&＃xff0c;这样&＃xff0c;内核程序和用户程序就可以同时访问这一区间了。

对于有 ring buffer 的网卡&＃xff0c;ring buffer 是由驱动与网卡共享的&＃xff0c;所以内核可以直接访问 ring buffer&＃xff0c;一般拷贝 frames 的副本到自己的内核空间进行处理(deliver 到上层协议&＃xff0c;之后的一个个 skb 就是按 skb 的指针传递方式传递&＃xff0c;直到用户获得数据&＃xff0c;所以&＃xff0c;对于 ring buffer 网卡&＃xff0c;大量拷贝发生在 frame 从 ring buffer 传递到内核控制的计算机内存里)。

4. 丢包排查思路

网卡工作在数据链路层&＃xff0c;数据量链路层&＃xff0c;会做一些校验&＃xff0c;封装成帧。我们可以查看校验是否出错&＃xff0c;确定传输是否存在问题。然后从软件层面&＃xff0c;是否因为缓冲区太小丢包。

先查看硬件情况

一台机器经常收到丢包的报警&＃xff0c;先看看最底层的有没有问题:

(1) 查看工作模式是否正常

[root&＃64;localhost ~]# ethtool eth0 | egrep &＃39;Speed|Duplex&＃39;Speed: 1000Mb/sDuplex: Full

(2) 查看检验是否正常

[root&＃64;localhost ~]# ethtool -S eth0 | grep crcrx_crc_errors: 0

Speed&＃xff0c;Duplex&＃xff0c;CRC 之类的都没问题&＃xff0c;基本可以排除物理层面的干扰。

overruns 和 buffer size

for i in &＃96;seq 1 100&＃96;; do ifconfig eth2 | grep RX | grep overruns; sleep 1; doneRX packets:346547657 errors:0 dropped:0 overruns:35345 frame:0-g   –show-ringQueries the specified ethernet device for rx/tx ring parameter information.-G   –set-ringChanges the rx/tx ring parameters of the specified ethernet device.ethtool -g eth0[root&＃64;localhost ~]Ring parameters for eth0:Pre-set maximums:RX: 4096RX Mini: 0RX Jumbo: 0TX: 4096Current hardware settings:RX: 256RX Mini: 0RX Jumbo: 0TX: 256ethtool -G eth0 rx 2048ethtool -G eth0 tx 2048[root&＃64;localhost ~][root&＃64;localhost ~][root&＃64;localhost ~]Ring parameters for eth0:Pre-set maximums:RX: 4096RX Mini: 0RX Jumbo: 0TX: 4096Current hardware settings:RX: 2048RX Mini: 0RX Jumbo: 0TX: 2048

Red Hat 官方解决思路

Issue

Why rx_crc_errors incrementing in the receive counter of ethtool -S output?

$ ethtool -S  | grep -i error     rx_error_bytes: 0     tx_error_bytes: 0     tx_mac_errors: 0     tx_carrier_errors: 0     rx_crc_errors: 9244     rx_align_errors: 0

Resolution

1. Change the cable.
2. Check switch configuration.
3. Change the network interface card.

Root Cause

1. Most of the time incrementing the value of rx_crc_errors means the problem is in Layer-1 of the networking model.
2. When a packet is received at the interface, it goes through a data integrity check which is called cyclic redundancy check. If the packet fails in that check, it is marked as rx_crc_errors.
3. The switch was forcing the NIC to operate in half-duplex mode. Fixing the switch to tell the NIC to operate in full-duplex mode have resolved the issue.

Diagnostic Steps

Check ethtool -S output and find where are the drops and errors.

$ ethtool -S  | grep -i error     rx_error_bytes: 0     tx_error_bytes: 0     tx_mac_errors: 0     tx_carrier_errors: 0     rx_crc_errors: 9244  >>>>>>     rx_align_errors: 0

Check the numbers corresponding to rx_crc_errors.

ethtool p1p1Settings for p1p1: Supported ports: [ FIBRE ] Supported link modes:   10000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes:  10000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 10000Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7)          drv probe link Link detected: yes

显示了 p1p1 的接口类型&＃xff0c;连接模式&＃xff0c;速率等等信息&＃xff0c;以及当前是否连接了网线(如果是网线 Supported ports 就是 TP&＃xff0c;如果是光纤则显示 Fiber)&＃xff0c;这里例举下 3 个重要关键词

Supported ports: [FIBRE]
Speed: 10000Mb/s
Link detected: yes

ethtool -S p1p1 | grep -i error     rx_errors: 0     tx_errors: 0     rx_over_errors: 0     rx_crc_errors: 0     rx_frame_errors: 0     rx_fifo_errors: 0     rx_missed_errors: 0     tx_aborted_errors: 0     tx_carrier_errors: 0     tx_fifo_errors: 0     tx_heartbeat_errors: 0     rx_length_errors: 0     rx_long_length_errors: 0     rx_short_length_errors: 0     rx_csum_offload_errors: 0ethtool -p ethtool -p eth0ethtool -i p1p1driver: ixgbeversion: 5.1.0-k-rh7.6firmware-version: 0x80000960, 18.3.6expansion-rom-version:bus-info: 0000:04:00.0supports-statistics: yessupports-test: yessupports-eeprom-access: yessupports-register-dump: yessupports-priv-flags: yesethtool -s eth0 speed 100

参考文章

ethtool[3]

Counters Troubleshooting for Linux Driver[4]

Why do I see rx_crc_errors in ethtool output?[5]

ping 请求错误分析[6]

ifconfig 命令详解[7]

ethtool 命令详解[8]

ethtool 解决网卡丢包严重和网卡原理[9]

脚注

[1]

RPS 和 RFS 网卡多队列性能调优实践: https://wsgzao.github.io/post/rps/

[2]

如何使用 MTR 诊断网络问题: https://wsgzao.github.io/post/mtr/

[3]

ethtool: https://mirrors.edge.kernel.org/pub/software/network/ethtool/

[4]

Counters Troubleshooting for Linux Driver: https://community.mellanox.com/s/article/counters-troubleshooting-for-linux-driver

[5]

Why do I see rx_crc_errors in ethtool output?: https://access.redhat.com/solutions/154543

[6]

ping 请求错误分析: https://blog.csdn.net/u011857683/article/details/83663316

[7]

ifconfig 命令详解: https://blog.csdn.net/u011857683/article/details/83758503

[8]

ethtool 命令详解: https://blog.csdn.net/u011857683/article/details/83758689

[9]

ethtool 解决网卡丢包严重和网卡原理: https://blog.csdn.net/u011857683/article/details/83758869