本文作者：AMD 賽靈思工程師GaofengZhao

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

問題描述:

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

測試過程：

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

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

雙方的網(wǎng)卡都工作在 MTU1500 模式下，故數(shù)據(jù)段長度設(shè)為 1472B，總帶寬暫設(shè)為 2400M。

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

解決方案：

使用 RFS 接收流導(dǎo)向，RFS 是 Linux 網(wǎng)絡(luò)協(xié)議棧提供的一項輔助性功能，RFS 的目標(biāo)是通過將數(shù)據(jù)包在內(nèi)核中的處理引導(dǎo)到使用該數(shù)據(jù)包的應(yīng)用程序線程對應(yīng)的 CPU 來提高數(shù)據(jù)緩存的命中率，詳情可參考 Linux 內(nèi)核文檔https://www.kernel.org/doc/html/latest/networking/scaling.html

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

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

總結(jié)：

使用 RFS 可以一定程度上解決 MPSoC 10G 以太網(wǎng)應(yīng)用(使用 MCDMA 時)中的 UDP 接收丟包問題，但是會產(chǎn)生額外的 CPU 開銷，如果丟包率在接受范圍內(nèi)可以選擇不開啟。