當今時代下，高性能網絡的需求日益增加，在圖形渲染被獨立成GPU、神經網絡計算被獨立成NPU后，網絡數據的加速也被提上日程，將網絡數據處理轉移到DPU上，成為了業內共識。
這篇文章，趁著我手里剛好有幾張DPU，我們就一起來看一下，DPU如何像GPU、NPU一樣，幫助加速云原生容器網絡。
一點題外話
在接觸DPU前，我一直覺得Open vSwitch（后文簡稱OVS）是一個處在黃昏時期的開源項目，是一個逐漸在被大家拋棄的東西。但是隨著我用Proxmox VE等一些虛擬化、超融合平臺以來，加之目前對DPU的適配工作，越發覺得OVS在業務性的SDN網絡中處在一個不一般的地位，生態非常豐富。
在以往，對于這種類似的需求，我可能會非常推崇使用Linux原生的協議棧，或者使用DPDK lib自己開發。但是現在看來，沒有比OVS再能all in one的方案了。Linux原生協議棧最大的問題就在于功能非常分散，簡言之，我通過一個OVS可以解決大多數軟轉的需求，無非有些細節之處實現不會特別優雅，但是有OVS的生態加持下，很容易就可以加持上DPDK、智能網卡、DPU。但是如果在Linux原生協議棧下，這個適配還是比較有挑戰性的，畢竟hook了FDB來 L2，還要再去hook FIB來 L3，然后還要再去hook 來 L4，這太難受了。
所以，在滿足99%需要的情況下，OVS還是沒毛病的，人家還在穩步成長中，也還沒到黃昏。
為什么會有DPU
由于網上對DPU的介紹非常多，此處我就不詳細描述了，這里我們就簡單聊聊為什么會有DPU。
網絡數據的轉發需求非常大，以我們常用的K8S網絡，它有這么這么多的需求需要滿足：
可以看到，網絡的需求有這么多，但是硬件的能力就那么點，所以讓一個硬件實現完整的功能支持并不現實，即便是FPGA也不能這樣既要又要，因此，把硬件和軟件轉發打包在一起組成一個DPU，就可以讓它去包辦所有網絡相關的工作，Host就只需要關注業務了。
DPU如何加速數據傳輸
博主我接觸容器場景比較多，這里我拿容器中落地比較多的SR-IOV方案來闡述。
容器場景（）和虛擬機有點不太一樣，他們雖然都算是基礎設施平臺，但是交付的資源的類型和對業務的感知程度有些許差別。在容器場景中，平臺能夠直接感知業務Pod的狀態，可以說離業務更近了，業務可靠性通過多副本實現，因此可以一定程度容忍Pod失敗。因此，容器場景下，不需要通過熱遷移來保證Pod高可用，SR-IOV非常適合。但是在虛擬機場景下，虛擬機要能夠支持熱遷移，不能引入硬件依賴，因此SR-IOV無法勝任，vDPA反而是最佳選擇。
在SR-IOV加速的方案中，DPU會有兩個職能部分（如下圖），一個是在通用芯片中運行的OVS-DPDK，來作為慢速路徑，一個是在ASIC/FPGA中的快速路徑（圖中為 path，卸載路徑），通過首包后下發的硬件規則（ rule）將數據包從VF到VF直接轉發，可以非常輕松達到線速，大幅提高性能。
這樣加速之后，就形成了一個效果，一條流（flow）的首包發出之后，只要知道它該去哪里了，我就把這個路徑告訴DPU，這樣DPU每次在查找匹配到這條流之后，就直接從另外端口發出（或者做一些其他操作）就好了，就不用再來問問慢速路徑該怎么走了，畢竟慢速路徑轉發也是靠通用芯片，效率肯定比不上ASIC/FPGA。通過這種抄近路的辦法，DPU就可以把數據傳輸加速了。
為什么要區分快速、慢速路徑
首先我們要知道無法找到網絡配適器的驅動程序，這兩條路徑是它們兩個間相對的。
快速路徑指的是可編程芯片（FPGA）或者專用芯片（ASIC）等中的轉發路徑，慢速路徑指的是通用芯片（x86、ARM等）中的轉發路徑。慢速路徑可以和快速路徑打包在一起組成DPU，也可以轉移到Host上，原理上區別不大。
快速路徑雖然很快，但是它只能實現簡單的操作，硬件級別Match/Action的能力有限，沒有辦法像慢速路徑的通用芯片那樣可以依靠多條指令處理非常復雜的轉發，因此快速路徑沒有辦法包攬業務的全部需求，需要慢速路徑出面，對快速路徑中硬件解決不了的轉發需求進行補盲，共同支撐DPU的功能。
下文，我們會再更加細致得來看看快速、慢速路徑是如何協同的。
SR-IOV的接口概念
SR-IOV技術最開始來源于虛擬機場景中，為了能夠實現更高的虛擬化效率，讓網卡“分身”成為PF和眾多的VF，就可以把VF通過硬件直通的方式直通到虛擬機中，這樣一來，就不再需要通過軟件來實現虛擬交換機了，就可以大幅提升網絡性能，并且減少虛擬化宿主CPU的壓力。
在SR-IOV這個過程中，共誕生出來了兩個產物，一個叫做PF，一個叫做VF。
其中，PF本身也是個接口，可以在Linux操作系統中用于數據傳輸，相對于VF的區別在于PF接口提供了額外的權限，可以用于管理整個網卡的功能無法找到網絡配適器的驅動程序，比如VF的數量。如下的代碼塊，就是PF設備的驅動提供的額外權限，可以用于創建VF，僅僅PF接口的驅動才會有這個文件。
echo "10" > /sys/class/net/ens6/device/sriov_numvfs
VF接口就是個實打實的接口了，可以把它理解為一個輕量的PCIe設備，僅僅只包含了最基礎的傳輸數據的功能。
在這個模型中，網卡更多還充當了一個硬交換機的角色（ Switch），眾多的VF實際上就是接在這么個交換機上，再通過網卡的物理接口，和外部網絡接通。
什么是VF
其實最開始我是覺得它應該歸屬到SR-IOV的范疇，但是之所以拆出來講，是隨著了解的深入，我覺得它更多算是SR-IOV的副產物，它并不算是SR-IOV這個硬件體系下的概念，只是各家軟件系統在為了對齊標準的網絡棧因而創造的概念。
VF （后文簡稱VF Rep），在DPDK中也叫做Port ，是DPDK在管理PF時由DPDK PMD驅動創建的接口，本質是個ethdev。在大多數情況下， rule（在DPDK中叫做traffic rule）是沒有辦法預先確定的，因此快速路徑必須要慢速路徑告知，通過接口將整一條flow下發到快速路徑，才能完成所謂的硬件加速。那么實現這樣的協同處理，網卡就必須要提供switch rule的other end選項，能夠將失配規則的流通過某一種方式送回軟件處理，這就是誕生的意義，翻譯成中文就是“代表”，也就可以理解成VF轉不動的包，就讓VF代表來，還是挺有意思的。
在有的智能網卡中，這個VF Rep也會被驅動支持，在Linux中呈現單獨的接口，其目的和DPDK中的一樣，都是為了能夠實現標準的網絡棧，能夠通過VF Rep上送的流量而已。
如何收包
了解了籠統的，再一起來看看DPDK里是如何處理VF Rep接口的收包的。
此處我拿Intel的ixgbe驅動來舉例，VF Rep的初始化流程大概為：
()
起初，我以為網卡會為每個數據包在頭端中添加額外的字段來標識這個數據包來自于哪個VF，隨著分析DPDK的代碼發現，其實并沒有這些邏輯，網卡本身只需要匹配 rule然后丟到合適的隊列就好了，失配的就成other end，丟到VF Rep的隊列，等慢速路徑的PMD拿走處理就好，整個環節似乎沒有理由再去添加專用的頭端域。
那么在這個過程中，網卡非常依賴大量的隊列，然而這些隊列又都是通過DMA映射的物理內存，考慮到VF與VF間的隔離，我相信這里投遞的disc，其內部的data也一定是從一個buf中復制到了另外的buf，應該不太可能能全部（吧？）。
因此，是不是可以得出一個結論，內存性能會非常影響網絡性能（僅在慢速路徑中）？
為了能夠更直觀一些，我畫了個圖來說明，如下圖。
圖中共兩條路徑A和B。
路徑A為快速路徑，即已經通過下發到硬件的flow信息，將會由硬件從VF的tx隊列中Match到，然后直接Action轉發到所選擇的VF的rx隊列中。
路徑B為慢速路徑，即當數據包在VF的tx隊列中Match時失配，通過VF Rep上送到OVS-DPDK，在UIO的OVS-DPDK中完整查表后，找到目的的VF Rep口并發出，最終就會被送回到關聯的VF口。最后，如果這一條流能夠被快速路徑加速，OVS-DPDK會再通過UIO驅動程序操作PF的寄存器，將這一條流的信息下發到快速路徑中，后續就可以實現硬件加速。
快速路徑的瓶頸
如果說本質上只是系統或者軟件的概念，那么意味著所有能夠支持SR-IOV并且能夠支持上送路徑的網卡，都可以作為快速路徑使用（推測，改天找機會測試一下）。
這里，我就拿一張Intel 82599為例，看看它能在快速路徑中發揮哪些作用。
在中，參考8.2 Device — PF的Flow 部分，可支持編程的字段不多，如下圖。
可能硬件與硬件間的區別，就在于能夠支持可編程的Match/Action的字段有多少了吧。
可編程的Match/Action字段越多，就支持更復雜的流的加速，相對而言就能分擔更多慢速路徑的負擔，提高整體的網絡性能。畢竟，在快速路徑上打滿線速還是比較容易的，而在慢速路徑上，大帶寬的小包滿線速就非常難了。
和智能網卡的區別
此處，我拿一張來自的膠片，來一起看看智能網卡會怎么處理。
如下圖，圖片名稱為OVS Hooks。
如下圖，圖片名稱為OVS-TC。
可以看到，智能網卡和DPU一樣，能夠對特定的flow進行加速（卸載），上邊的兩幅圖中都是硬件加速，只是實現的方式不同而已，但是最終都只是實現了快速路徑，慢速路徑的工作仍然還留在Host上。而DPU，可以把快速路徑和慢速路徑都轉移到自己身上，這可能就是和智能網卡的最大差別吧。
總結
整體上來講，我覺得DPU之所以能夠被叫做DPU而不是智能網卡，是因為DPU不僅可以和智能網卡一樣加速多種流，同時還整合了通用芯片來運行慢速路徑，這兩條路徑協同起來，整體上看起來DPU才是真正一個獨立的、可以處理一切流量的網絡處理單元，才能從Host上解放了網絡處理的工作，整體上提高網絡的性能，讓Host更加專注業務本身。
參考資料