【寫在前面】飛騰開發者平台是基於飛騰自身強大的技術基礎和開放能力，聚合行業內優秀資源而打造的。該平台覆蓋了操作系統、算法、數據庫、安全、平台工具、虛擬化、存儲、網絡、固件等多個前沿技術領域，包含了應用使能套件、軟件倉庫、軟件支持、軟件適配認證四大板塊，旨在共享尖端技術，為開發者提供一個涵蓋多領域的開發平台和工具套件。點擊這裏開始你的技術升級之旅吧
本文分享至飛騰開發者平台《GMAC網絡延時性能優化》
1 問題介紹及分析
1.1 問題介紹
問題簡介：D2000 板載GMAC網卡，netperf測試網絡時延，相較於i350 80μs左右的時延水平。差距接近在5倍左右。
即：兩塊GMAC網卡對接，時延在500μs以上。GMAC網卡與i350網卡對接，時延在350μs左右。
測試情況：
測試結果：
| 測試端1 | 測試端2 | 時延（μs） |
|---|---|---|
| FT-2000/4 GMAC | FT-2000/4 GMAC | 550 |
| D2000 GMAC（netserver） | FT-2000+/64 i350（client） | 350 |
| D2000 GMAC（client） | FT-2000+/64 i350（netserver） | 341 |
| D2000 i350 | FT-2000+/64 i350 | 82 |
| FT-2000+/64 i350 | FT-2000+/64 i350 | 77 |
性能對比如下圖,D2000 gmac 與FT-2000+/64 i350，分別作為netperf的client與server端的時延為341μs和350μs，取兩者的平均值：345μs
未優化前性能對比:
1.2 問題分析
網絡時延：時延是指一個報文或分組從一個網絡的一端傳送到另一個端所需要的時間。它包括了發送時延，傳播時延，處理時延，排隊時延。Netperf源碼
測試流程分析：
1）每一輪傳輸取開始的時間：
2）每一輪結束取結束的時間：
3）將結束時間和開始時間作為入參，調用HIST_add;
4）HIST_add函數，會將傳輸次數++，然後算出最大延遲和最小延遲病存儲
5）整個測試結束，調用計算延遲的接口HIST_get_stats
6）HIST_get_stats會最終算出最大延遲，最小延遲，已經平均延遲
通過netperf源碼獲知：網絡時延測試就是客户端向服務端發送報文。服務端收到報文，發出回覆報文，客户端收到回覆報文作為一次傳輸過程，計時（存儲在數組中），作為本次傳輸的時間。累計在固定時間內，重複以上過程，記錄傳輸過程（有來有回）的次數，以及每次傳輸對應的時間。從而在所有計時（數組），算出最大時延，最小時延，以及平均時延（所有時間相加/傳輸次數）。
針對以上時延測算過程：發送時延（如果是發送方是i350）和傳播時延可以忽略不計。主要對接收方（GMAC）處理時延和排隊時延的優化。因此針對這一優化目標，主要就以下幾個方面進行優化：
2 優化策略
2.1 協議棧參數優化
以下參數所在文件目錄：/proc/sys/net/ipv4/ 以及/proc/sys/net/core/
| 名稱 | 默認值 | 調優值 |
|---|---|---|
| net.ipv4.tcp_mem | 178305 237740 356610 | 786432 1048576 1572864 |
| net.ipv4.tcp_wmem | 4096 16384 4194304 | 8192 131072 16777216 |
| net.ipv4.tcp_rmem | 4096 87380 6291456 | 32768 131072 16777216 |
| net.ipv4.tcp_syn_retries | 6 | 1 |
| net.core.somaxconn | 128 | 16384 |
經過測試，以上調優手段，對時延影響不大。
2.2 Tcp分段設置
原理：當一個系統需要通過網絡發送一大段數據時，計算機需要將這段數據拆分為多個長度較短的數據，以便這些數據能夠通過網絡中所有的網絡設備，這個過程被稱作分段。TCP分段卸載將TCP的分片運算（如將要發送的1M字節的數據拆分為MTU大小的包）交給網卡處理，無需協議棧參與，從而降低CPU的計算量和中斷頻率。雖然此種修改方式能夠提高帶寬。但是這樣勢必會增加時延，所以建議關閉。該部分詳細內容可以參考：http://t.zoukankan.com/huaweicloud-p-11861181.html
修改方式：使用ethtool工具關閉網卡和驅動對TSO（TCP Segmentation Offload）的支持。如下命令中的參數“$eth”為待調整配置的網卡設備名稱，如eth0，eth1等。
# ethtool -K $eth tso off
經過測試，以上調優手段，對時延影響不大。
2.3 中斷聚合參數調整
原理：中斷聚合特性允許網卡收到報文之後不立即產生中斷，而是等待一小段時間有更多的報文到達之後再產生中斷，這樣就能讓CPU一次中斷處理多個報文，減少開銷。
兩種修改方式：
1）使用ethtool -C $eth方法調整中斷聚合參數。其中參數“$eth”為待調整配置的網卡設備名稱，如eth0，eth1等。
# ethtool -C eth3 adaptive-rx off adaptive-tx off rx-usecs N rx-frames N tx-usecs N tx-frames N為了確保使用靜態值，需禁用自適應調節，關閉Adaptive RX和Adaptive TX。
rx-usecs：設置接收中斷延時的時間。
tx-usecs：設置發送中斷延時的時間。
rx-frames：產生中斷之前接收的數據包數量。
tx-frames：產生中斷之前發送的數據包數量。
這4個參數設置N的數值越大，中斷越少。帶寬越大，時延越大。
因此建議將以上4個設置N數字變小。從而降低時延。但是gmac網卡暫不支持ethtool此種設置方式。
關於調整中斷聚合的詳細內容可以參考：https://www.sohu.com/a/352508214_655101
2）通過修改內核代碼的方式
通過修改源碼中表徵中斷聚合參數的值，控制中斷產生的頻率，為降低時延，我們作一下修改：
| 修改項目 | 修改前 | 修改後 |
|---|---|---|
| #define MAX_DMA_RIWT | 0xff | 0x20 |
修改完成，重新編譯內核源碼，詳細測試結果見第三章。
3 測試結果
經過2.4 章中，中斷聚合優化以後的測試：
測試拓撲：
表 FT-2000+/64(i350 client)\<-\>D2000(gmac server)
| 測試次數 | 時延（μs） |
|---|---|
| 1 | 93.37 |
| 2 | 93.03 |
| 3 | 93.04 |
| 4 | 93.69 |
| 5 | 94.80 |
| 平均值 | 93.59 |
表 FT-2000+/64(i350 server)\<-\>D2000(gmac client)
| 測試次數 | 時延（μs） |
|---|---|
| 1 | 96.57 |
| 2 | 97.91 |
| 3 | 95.69 |
| 4 | 97.90 |
| 5 | 94.19 |
| 平均值 | 96.45 |
測試結論：netperf時延測試，gmac作為server端和client端，時延分別在93.59和96.45左右，取兩者的平均值：95μs左右
4 測試結論
經過中斷聚合參數調整以後，前後網絡時延性能對比：
測試結論：優化後，gmac無論作為netperf的server端或者作為client時，性能提升接近4倍左右，接近兩塊intel i350網卡互連時時延的水平（80μs左右）。
推薦閲讀
- 基於飛騰騰鋭D2000的DPDK適配及測試指南
- 飛騰平台上Hyperscan安裝測試指南
歡迎廣大開發者來飛騰開發者平台獲取更多前沿技術文檔及資料
如開發者在使用飛騰產品有任何問題可通過在線工單聯繫我們
版權所有。飛騰信息技術有限公司 2023。保留所有權利。
未經本公司同意，任何單位、公司或個人不得擅自複製，翻譯，摘抄本文檔內容的部分或全部，不得以任何方式或途徑進行傳播和宣傳。
商標聲明
Phytium和其他飛騰商標均為飛騰信息技術有限公司的商標。
本文檔提及的其他所有商標或註冊商標，由各自的所有人擁有。
注意
本文檔的內容視為飛騰的保密信息，您應當嚴格遵守保密任務；未經飛騰事先書面同意，您不得向任何第三方披露本文檔內容或提供給任何第三方使用。
由於產品版本升級或其他原因，本文檔內容會不定期進行更新。除非另有約定，本文檔僅作為使用指導，飛騰在現有技術的基礎上盡最大努力提供相應的介紹及操作指引，但飛騰在此明確聲明對本文檔內容的準確性、完整性、適用性、可靠性的等不作任何明示或暗示的保證。
本文檔中所有內容，包括但不限於圖片、架構設計、頁面佈局、文字描述，均由飛騰和/或其關聯公司依法擁有其知識產權，包括但不限於商標權、專利權、著作權等。非經飛騰和/或其關聯公司書面同意，任何人不得擅自使用、修改，複製上述內容。
