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/

【完】