科技鼻祖系列
原文链接：
前言
之前有记录并处理过由于LVS网卡流量负载过低导致软中断导致丢包的问题。 RPS和RFS网卡的多队列性能调优实践[1]，虽然对于普通人来说压力不高，虽然遇到的概率也不高。 这次我要分享的主题是如何排查常见的服务器网卡丢包现象。 如果你想了解点对点丢包的解决方案，可能会涉及到很广泛的想法。 大家不妨参考一下之前的文章《如何使用MTR诊断网络问题[2]》，对于Linux中常用的网卡丢失分析工具自然是很熟悉了。
用于查看和更改网络设备（尤其是有线以太网设备）的驱动程序参数和硬件设置。 您可以根据需要修改以太网卡的参数，包括手动协商、速度、双工、网络唤醒等参数。 通过配置以太网卡，您的计算机可以通过网络进行有效的通信。 该工具提供了有关连接到 Linux 系统的以太网设备的大量信息。
1.了解接收数据包的过程
以下是美团技术团队的分析，在此谢谢
接收数据包是一个复杂的过程，涉及到很多底层技术细节，但一般需要以下步骤：
NIC 接收数据包。
将数据包从 NIC 硬件缓存传输到服务器视频内存。
通知内核进行处理。
通过TCP/IP契约逐层处理。
应用程序通过 read() 读取数据。
将网卡收到的数据包传输到主机显存（网卡与驱动交互）
网卡收到数据包后，首先需要将数据同步到内核，中间的桥梁就是。 它是网卡和驱动程序共享的区域。 事实上，存储的并不是实际的数据，而是一个描述符。 该描述符指向其真实的存储地址。 具体流程如下：
驱动程序在显存中分配一个缓冲区来接收数据包，称为；
将上述缓冲区（即接收描述符）的地址和大小添加到中。 描述符中的缓冲区地址是DMA使用的数学地址；
驱动程序通知网卡有新的描述符；
网卡从中取出描述符，然后就知道缓冲区的地址和大小；
网卡收到新的数据包；
网卡通过DMA直接向网络发送新的数据包。
当驱动程序的处理速度跟不上网卡的数据包接收速率时，驱动程序来不及分配缓冲区，网卡接收到的数据包无法及时上报，就会形成堆积。 当网卡内部缓冲区已满时，其中一些将被丢弃。 数据，导致丢包。 这部分丢包表现为/proc/net/dev中fifo数组的下降，以及.
通知系统内核进行处理（驱动与Linux内核交互）
此时，数据包已经传输到 。 前面提到，这是驱动程序在显存中分配的缓冲区，并且是通过DMA写入的。 这些方法不依赖CPU直接将数据传输到显存，这意味着对于内核来说，虽然它不知道显存中已经有新的数据。 那么如何让内核知道有新数据进来了呢？ 答案就是中断，它通过中断告诉内核有新的数据进来了，需要进行后续的处理。
说到中断，就涉及到硬中断和软中断。 首先，您需要简单了解一下它们的区别：
当网卡通过DMA将数据包复制到内核缓冲区时，网卡立即发起硬件中断。 CPU收到后，首先进入上部。 网卡中断对应的中断处理程序是网卡驱动的一部分，然后它发起软中断，进入下层，开始消费数据，交给契约栈处理。
只有通过中断我们才能快速及时的响应网卡数据请求，但是如果数据量很大的话，这会造成大量的中断请求，CPU大部分时间都会忽略处理中断物理网卡mac怎么修改，而效率很低。 为了解决这个问题，当今的内核和驱动程序使用一种称为NAPI（）的方法来进行数据处理。 原理可以简单理解为中断+寻址。 返回数据包数量以防止多次中断。
2. 解释
[root@localhost ~]
eth0: flags=4163 mtu 1500
inet 192.168.1.135 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::20c:29ff:fe9b:52d3 prefixlen 64 scopeid 0x20<link>
ether 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 0
TX packets 122 bytes 9028 (8.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(1) 接收端
表示接收到的数据包错误总数，包括too-long-、Ring 错误、crc校验错误、帧同步错误、fifo和pkg等。
(2) 接收端
表示数据包已经进入Ring，但由于显存不足等系统原因，在复制到显存的过程中被丢弃。
(3) 接收
表示fifo，这是因为Ring（又称Queue）传输的IO小于可以处理的IO，而Ring指的是发起IRQ请求之前的块。 显然，数据包的减少意味着数据包在到达环之前就被网卡的化学层丢弃了，而CPU无法处理中断是环满的原因之一。 里面有问题的机器是由于分布不均匀（全部压在core0上），不做造成的丢包。
(4)接收帧
表达。
三、网卡工作原理
如果觉得接收数据包的过程还不够详细，可以阅读明文解释
网卡接收数据包
网络线路上的数据首先由网卡获取，网卡会检测CRC校验以保证完整性，然后去掉报头得到帧。 网卡会检测MAC数据包中的目的MAC地址，如果与网卡的MAC地址不同，则将其丢弃（混杂模式除外）。
网卡将帧复制到网卡内部的FIFO缓冲区，并触发硬件中断。 （如果有网卡有环，好像可以先将帧存入环中，然后触发软件中断（上一篇文章会详细讲解Linux中帧的方向），环是共享的由网卡和驱动程序组成，它是设备中的显存，它对于运行系统来说是可见的，因为linux内核源码中的网卡驱动程序是用来分配空间的，所以环通常有上限，另外，应该表示可以存储的帧数，而不是字节大小。另外，有些系统命令不能通过改变ring来设置ring的大小，不知道为什么，可能是驱动不支持。）
通过硬中断处理函数建立网卡驱动，将帧从网卡FIFO复制到显存skb，然后交给内核处理。 （支持napi的网卡应该直接放在环中，不触发硬中断，直接使用软中断，复制环中的数据，直接发送到下层处理。每个网卡可以处理一帧1个软中断处理流程）
在此过程中，网卡芯片对帧进行MAC过滤，以减轻系统负载。 （不仅仅是混杂模式）
网卡分包
网卡驱动程序在IP数据包中添加14字节的MAC头，形成帧（暂时没有CRC）。 帧（目前没有 CRC）富含发送方和接收方的 MAC 地址。 因为驱动程序创建了MAC头，所以可以随意输入地址，还可以进行主机伪装。
驱动程序将帧（不带CRC）复制到网卡芯片内部的缓冲区，由网卡处理。
网卡芯片将要发送的不完整帧（不带CRC）重新封装，即添加腹同步信息和CRC校准，然后扔到网线上，完成一条IP报文的发送。 NIC 可以看到这一点。
网卡中断处理程序
每个引起中断的设备都有一个相应的中断处理程序，它是设备驱动程序的一部分。 每个网卡都有一个中断处理程序，用于通知网卡已经收到中断，并将网卡缓冲区中的数据包复制到显存中。
当网卡收到来自网络的数据包时，需要通知内核数据包已经到达。 NIC 立即发出中断。 内核通过执行网卡已注册的中断处理函数来响应。 中断处理程序开始执行，通知硬件，将最新的网络数据包复制到显存，然后从网卡读取更多的数据包。
这都是重要、紧急、与硬件相关的工作。 内核一般需要快速将网络数据包复制到系统显存，因为网卡接收网络数据包的缓冲区大小是固定的，但比系统显存小很多。 因此，一旦上述的复制动作被延迟，必然会导致网卡 FIFO 缓冲区溢出——传入的数据包占用了网卡的缓冲区，后续的数据包只能被丢弃，这也应该是根源的数据。
当网络数据包被复制到系统内存时，中断的任务就被认为完成了，然后将控制权返回给系统中断之前正在运行的程序。
缓冲区访问
网卡的内核缓冲区在PC显存中，由内核控制，而网卡有一个FIFO缓冲区或环，应该区分两者。 FIFO比较小，如果上面有数据物理网卡mac怎么修改，它会尝试将数据存储到内核缓冲区中。
网卡中的缓冲区既不属于内核空间也不属于用户空间。 属于硬件缓冲区，允许网卡和操作系统之间有一个缓冲区；
内核缓冲区位于内核空间，在显存中，供内核程序使用，作为从硬件读取或写入硬件的数据缓冲区；
用户缓冲区位于用户空间，在显存中，供用户程序使用，作为从硬件读取或写入的数据缓冲区；
另外，为了促进数据交互，可以将内核缓冲区映射到用户空间，以便内核程序和用户程序可以同时访问该区域。
对于带ring的网卡，ring是驱动和网卡共享的，因此内核可以直接访问ring，通常会将复制的副本复制到自己的内核空间进行处理（到下层合约，然后每个skb 是根据 skb 指针传递的，直到用户获得数据，所以，对于环网卡来说，当帧从环传递到内核控制的计算机显存时，会发生大量的副本）。
4.丢包排查思路
网卡工作在数据链路层和数据量链路层，会做一些校准，封装成帧。 我们可以查看校准是否错误，并确定传输是否存在问题。 然后从软件层面看是否因为缓冲区太小而丢包。
首先检查硬件
一台机器经常收到丢包的报告，首先检查底层是否有问题：
(1)检查工作模式是否正常
[root@localhost ~]# ethtool eth0 | egrep 'Speed|Duplex'
Speed: 1000Mb/s
Duplex: Full
(2)检查检查是否正常
[root@localhost ~]# ethtool -S eth0 | grep crc
rx_crc_errors: 0
Speed、、CRC之类的都可以，化学干扰基本可以排除。
和尺寸
for i in `seq 1 100`; do ifconfig eth2 | grep RX | grep overruns; sleep 1; done
RX 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@localhost ~]
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 256
RX Mini: 0
RX Jumbo: 0
TX: 256
ethtool -G eth0 rx 2048
ethtool -G eth0 tx 2048
[root@localhost ~]
[root@localhost ~]
[root@localhost ~]
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 2048
RX Mini: 0
RX Jumbo: 0
TX: 2048
红帽官方解决方案
问题
为什么是of-S？
$ 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
电缆。
查看。
卡片。
根本原因
大多数时候， 的值意味着 位于模型的第 1 层。
当它出现时，它会进行数据检查，即检查。如果检查失败，则为。
网卡处于半模式。 告诉 NIC 进入完整模式有问题。
脚步
检查沙子找到水滴和的位置。
$ 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
检查一下。
ethtool p1p1
Settings 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的类型、连接模式、速度等信息，以及当前是否连接网线（如果是网线口则显示TP，如果是光纤则显示Fiber） ，这是接下来的三个重要关键字
端口：[光纤]
速度：/秒
链接：是的
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: 0
ethtool -p
ethtool -p eth0
ethtool -i p1p1
driver: ixgbe
version: 5.1.0-k-rh7.6
firmware-version: 0x80000960, 18.3.6
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
ethtool -s eth0 speed 100
参考文章
[3]
对于Linux[4]
为什么我看进去了？ [5]
Ping请求错误分析[6]
命令解释[7]
命令解释[8]
解决网卡丢包严重及网卡原理[9]
页脚
[1]
RPS和RFS网卡多队列性能调优实践：
[2]
如何使用MTR诊断网络问题：
[3]
:
[4]
对于Linux：
[5]
为什么我看到？：
[6]
Ping请求错误分析：
[7]
命令解释：
[8]
命令解释：
[9]
解决网卡丢包严重及网卡原理：
你可能还喜欢
点击下图阅读
太棒了，这个利器可以在几分钟内将多个合并为一个！
云原生是一种信念