ethdmaitr

⑴ ethtool原理介绍和解决网卡丢包排查思路

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

2020年06月22日 - 初稿

阅读原文 - https://wsgzao.github.io/post/ethtool/

ethtool - utility for controlling network drivers and hardware

ethtool is the standard Linux utility for controlling network drivers and hardware, particularly for wired Ethernet devices. It can be used to:

Most features are dependent on support in the specific driver. See the manual page for full information.

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

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

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

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

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

提到中断，就涉及到硬中断和软中断，首先需要简单了解一下它们的区别：

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

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

(1) RX errors

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

(2) RX dropped

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

(3) RX overruns

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

(4) RX frame

表示 misaligned 的 frames。

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

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

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

过程中，网卡芯片对frame进行了MAC过滤，以减小系统负荷。（除了混杂模式）

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

驱动程序将frame（暂无CRC）拷贝到网卡芯片内部的缓冲区，由网卡处理。

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

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

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

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

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

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

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

内核缓冲区在内核空间，在内存中，用于内核程序，做为读自或写往硬件的数据缓冲区；

用户缓冲区在用户空间，在内存中，用于用户程序，做为读自或写往硬件的数据缓冲区；

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

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

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

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

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

(2) 查看检验是否正常

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

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

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

Check the numbers corresponding to rx_crc_errors .

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

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

ethtool

Counters Troubleshooting for Linux Driver

Why do I see rx_crc_errors in ethtool output?

ping请求错误分析

ifconfig 命令详解

ethtool 命令详解

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

⑵ 华为5700交换机eth接口做什么用的怎么使用它

华为5700交换机eth可以作为管理口使用，交换机操作系统丢了 ，但是我可以通过eth口上传操作系统文件，跟console口的功能是类似的。

华为交换机从网桥发展而来，属于OSI第二层即数据链路层设备。它根据MAC地址寻址，通过站表选择路由，站表的建立和维护由CISCO思科交换机自动进行。

华为在美国、德国、瑞典、俄罗斯、印度以及中国的北京、上海和南京等地设立了多个研究所，近一半的员工从事着产品与解决方案的研发工作。

(2)ethdmaitr扩展阅读

华为是全球领先的电信解决方案供应商。我们拥有热诚的员工和强大的研发能力，快速响应客户需求，提供端到端的客户化产品、解决方案和服务，全力帮助客户商业成功，并通过我们的共同努力，不断丰富人们的沟通和生活。

华为产品和解决方案涵盖移动（LTE/HSPA/WCDMA/EDGE/GPRS/GSM, CDMA2000 1xEV-DO/CDMA2000 1X, TD-SCDMA和WiMAX）

核心网（IMS, Mobile Softswitch, NGN）、网络（FTTx, xDSL, 光网络, 路由器和LAN Switch）、电信增值业务（IN, mobile data service, BOSS）和终端（UMTS/CDMA）等领域。

⑶ 【NIC】如何使用 ethtool 命令管理以太网卡

ethtool 是一个 Linux 下的网络驱动程序的诊断和调整工具，可获取网络设备的相关信息，包括连接状态、驱动版本、PCI 总线定位等等。

它可以用来：

获取标识和诊断信息
获取扩展的设备统计信息
控制以太网设备的速度、双工、自动协商和流控制
控制校验和卸载及其他硬件卸载功能
控制 DMA 环大小及中断控制
控制多队列设备的接收队列选择
升级闪存中的固件

万兆网卡，理论最大支持 1250MB/s 实际 能有 几百MB /s 就不错了，要考虑交换机的能力。

如何使用 ethtool 命令管理以太网卡
https://zhuanlan.hu.com/p/146383216

ethtool工具使用实例
https://www.cnblogs.com/taosiyu/p/13425774.html

Linux网络命令——ifconfig、ifup、ifdown
https://blog.csdn.net/lu_embedded/article/details/53215324

ethtool(8) - Linux man page
https://linux.die.net/man/8/ethtool

ethtool : How to use ethtool command in Linux with examples
https://cmdref.net/os/linux/command/ethtool.html

ethtool - Unix, Linux Command
https://www.tutorialspoint.com/unix_commands/ethtool.htm

⑷ dsp问题求教。这个程序看了好久不懂，求大神指教，在线等

大概看了下 应该是用DMA实现乒乓缓存
以下是我猜的哈
while循环等待 DMA中断 或者DMA寄存器状态改变
然后DMA配置重置
下面的程序是对DMA搬得数进行乒乓缓存
然后开启DMA继续搬数

具体DMA搬数的方式和地址要看DMA的配置

⑸ ZYNQ+linux网口调试笔记（3）PL-ETH

在ZYNQ上使用gigE Vision协议的网络接口相机。

第一步：调通PS侧网口GEM0（Xilinx BSP默认配好）。

第二步：调通PS侧网口GEM1（见前一篇文档：开发笔记(1)）。

第三步：调通PL侧网口（本文阐述）。

第四步：在PL侧网口上验证Jumbo Frame特性，并在应用层适配gigE Vision协议。

根据《xapp1082》可知，PL侧的PHY支持1000Base-X和SGMII两种配置，这两种配置对应两种不同的PHY引脚接口（连接到MAC）。而我们的hdf文件使用的是1000Base-X的配置。

关于网口的Linux驱动，我们在官网找到一份资料： Xilinx Wiki - Zynq PL Ethernet 。资料很长，我们只看与我们相关的2.4.1 PL Ethernet BSP installation for 1000Base-X”这一章节就可以了。

首先导入FPGA设计同事提供的hdf文件：

在弹出的图形界面里，进入Subsystem AUTO Hardware Settings——Ethernet Settings——Primary Ethernet，确认可以看到PL侧网络设备axi_ethernet_0，说明hdf文件里已包含了必要的网口硬件信息：

上图中被选中的网口将成为Linux上的设备eth0。这里我们默认选择ps7_ethernet_0，即使用GEM0作为首选网口。

启用Xilinx AXI Ethernet驱动

进入Device Drivers -- Network device support – 选中Xilinx AXI Ethernet（以及Xilinx Ethernet GEM，这是PS侧网口的驱动）

进入Networking support – 选中 Random ethaddr if unset

进入Device Drivers -- Network device support -- PHY Device support and infrastructure – 启用Drivers for xilinx PHYs

进入~~~~Device Drivers -- DMA Engine Support -– 禁用~~~~Xilinx AXI DMAS Engine~~~ （对应的配置项名为 ~~ CONFIG_XILINX_DMA ~~~）

注意： Xilinx Wiki里对设备树节点的引用有误（&axi_ethernet），导致编译报错，应改为&axi_ethernet_0。

注：PL-ETH驱动所在路径：<project>/build/tmp/work-shared/plnx_arm/kernel-source/drivers/net/ethernet/xilinx/xilinx_axienet_main.c和xilinx_axienet_mdio.c。对应的内核配置项为CONFIG_NET_VENDOR_XILINX和CONFIG_XILINX_AXI_EMAC。

启用ethtool和tcpmp（调试用，非必须）：

然后将生成的BOOT.BIN和image.ub拷贝到SD卡根目录下，将SD卡插入板子上，上电运行。

上电后，使用ifconfig eth1查看网口信息，观察MAC地址与设置的一致，且ifconfig eth1 192.168.1.11 up没有报错。

测试网络通路：ping PC是通的。说明网口工作正常。

Linux下eth1（即PL-ETH）的MAC地址有误

问题描述：

开机打印：

注意：

MAC地址是错的，驱动里解析出的是GEM0的MAC地址。

试验发现，即使在system-user.dtsi里不写local-mac-address，也照样解析出的是GEM0的MAC。

而将system-user.dtsi里的local-mac-address改名为pl-mac-address，并将驱动里解析的字符串也对应更改为pl-mac-address，则可以正确解析出来：

Passing MAC address to kernel via Device Tree Blob and U-Boot：

http://zedboard.org/content/passing-mac-address-kernel-device-tree-blob

通过更改u-boot环境变量和设备树，为每个板子设置一个独特的MAC地址：

https://www.xilinx.com/support/answers/53476.html

U-Boot里的环境变量ethaddr会覆盖掉设备树里pl-eth的local-mac-addr字段，从而影响Linux启动后的网卡MAC地址；

但U-Boot里的环境变量ipaddr不会对Linux启动后的配置产生任何影响。因为设备树里根本就没有关于IP地址的配置。

phy-mode怎么会是sgmii？查了下官方的提供的BSP里，也是“sgmii”。说明这个没问题。具体原因不清楚。

@TODO: 设备树里的中断号的顺序如何影响功能？

为何读出来的IRQ号不对呢？这是因为这里读到的不是硬件的中断号，而是经过系统映射之后的软件IRQ number。两者不具有线性关系。

关于中断号的疑问：

Linux上的网口eth0、eth1的顺序，似乎是按照phy地址从小到大来排布的。

Xilinx xapp1082-zynq-eth.pdf (v5.0) July 16, 2018

https://www.xilinx.com/support/documentation/application_notes/xapp1082-zynq-eth.pdf

Xilinx Wiki - Zynq PL Ethernet:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841633/Zynq+PL+Ethernet

Xilinx Wiki - Linux Drivers:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841873/Linux+Drivers

Xilinx Wiki - Linux Drivers - Macb Driver:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver

Xilinx Wiki - Zynq Ethernet Performance:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841743/Zynq+Ethernet+Performance

查到关于Jumbo frame MTU的定义，当前值为9000，可否改大一些？

驱动源码里关于jumbo frame的说明：

设置MTU为9000，发现ping包最大长度只能设为ping 192.168.1.10 -s 1472

https://lore.kernel.org/patchwork/patch/939535/

【完】