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

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

問題描述:

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

測(cè)試過程：

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

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

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

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

解決方案：

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

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

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

總結(jié)：

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