本文介紹如何使能 Linux 網絡協議棧中的 RFS(receive flow steering)功能以優化 MPSoC APU 的并行處理能力，解決丟包問題。

問題描述:

在測試 ZCU102 PL 10G Ethernet with MCDMA 設計的性能時，遇到 UDP 接收丟包率很高的情況，測試使用的工具是 iperf3。

測試過程：

Board side：在 core1~3 上各開一個 iperf3 服務端用于收包，命令如下:

Server side：使用與 zcu102 用光纖相連的服務器發送 UDP 幀，命令如下:

雙方的網卡都工作在 MTU1500 模式下，故數據段長度設為 1472B，總帶寬暫設為 2400M。

測試結果如上圖所示，丟包率超過了百分之十，故實際傳輸速度也達不到設定的帶寬，使用 mpstat 命令觀察 CPU 使用狀況，發現接收工程中 CPU0 的軟中斷占用達到93.3%。

解決方案：

使用 RFS 接收流導向，RFS 是 Linux 網絡協議棧提供的一項輔助性功能，RFS 的目標是通過將數據包在內核中的處理引導到使用該數據包的應用程序線程對應的 CPU 來提高數據緩存的命中率，詳情可參考 Linux 內核文檔https://www.kernel.org/doc/html/latest/networking/scaling.html

在本文的測試中 Board side 上運行了三個 iperf 服務端在三個 CPU 上，RFS 可以將發給某個服務端的數據包的部分處理工作交給這個服務端對應的 CPU 執行，以此平衡工作負載。
按照文檔中的說明，rps_sock_flow_entries 設置為32768，本文使用的設計中 MCDMA 共有16個接收通道，所以 rps_flow_cnt 為32768/16=2048，另外共開啟了三個 iperf 服務端，所以暫時只設置 rx-0~rx-2，綜上，執行命令如下：

重新測試后結果如上圖所示，丟包率大大降低，實際傳輸速度也達到了設定值，使用 mpstat 命令監控傳輸期間的 CPU 狀況，發現 CPU0 的軟中斷占用時間降低，而 CPU1~3 的軟中斷占用升高，可以看出實現了負載的分配，但是從總體來看，四個 CPU 的總負載升高，說明 RFS 還是有一定的額外工作開銷。

總結：

使用 RFS 可以一定程度上解決 MPSoC 10G 以太網應用(使用 MCDMA 時)中的 UDP 接收丟包問題，但是會產生額外的 CPU 開銷，如果丟包率在接受范圍內可以選擇不開啟。
責任編輯：彭菁