在剛剛結束的“2020虛擬開發人員和測試論壇”上，來自瞻博網路的工程師Kiran KN和同事，介紹了在Tungsten Fabric資料平面上完成的一組效能改進（由Intel DDP技術提供支援），以下為論壇技術分享的精華：
在深入到DDP技術之前，首先介紹一下vRouter，它是什麼，以及在整個Tungsten Fabric框架中的位置。
實際上，vRouter可以部署在常規X86伺服器上，也可以在OpenStack或K8s的計算節點當中。vRouter是主要的資料平面元件，有兩種部署的模式，分別是vRouter:kernel module，以及vRouter:DPDK模式。
在用DPDK改善效能之前，此用例將涉及DPDK應用和vRouter。vRouter的職責是資料平面，用於資料包轉發和由vRouter代理在計算節點上程式設計的資料包轉發，但實際上，整個配置是透過控制器上的XMPP提供的。我們使用XMPP透過vRouter agent與控制器通訊，並且有一個專門的介面來對vRouter資料平面進行程式設計以轉發軟體包。
在DPDK中，vRouter是一個高效能、多核和多執行緒的應用程式，這裡想強調一下，它是專用於多核的DPDK應用，我們需要尋找多核的正確用法。
我們可以從示例中看到，網路卡具有與vRouter相同數量的佇列，已為資料包或連結分配了核心。
首先，資料包需要由網路卡平均地分配到所有路由器轉發核心。為此，使用了帶有5元組雜湊的演算法，在所有核心之間正確分配流量。而且，適當的負載平衡是基於資料包的，並且要實現該資料包需要具有5元組，多個源的目標埠IP地址。如果該協議正確，則該協議可以確定所有核心之間的流量平均分配，並且我們可以利用它分配給vRouter DPDK的所有核心的效能。儘管此流量包分佈在各個處理核心上，但可以透過TX介面佇列，將它們適當地放置到虛擬機器中。
如果此流量在各個核心之間沒有得到適當的平衡，則vRouter將在沒有核心的情況下進行重新平衡，但是對於核心來說，透過核心重新雜湊化它們的代價很高，這意味著它們會消耗CPU週期並帶來額外的延遲。
這就是我們面臨的問題，但在今天得到了很大程度的解決，我們可以期待網路卡能夠完成此任務，並適當地平衡vRouter核心之間的流量。
也就是說，具有MPLSoGRE的計算型別沒有足夠的熵（entropy）。由於熵的存在，我們的報頭中沒有足夠的資訊，或無法正確平衡資料包的負載。
具體來說，資料包應該具有完整的埠資訊，包含完整的5個要素，即源IP、目標IP、源埠、目標埠和協議。但是在MPLSoGRE只有源IP、目標IP和協議三元組資訊。因此，網路卡無法適當地平衡資料包的負載，由於該CPU核心，一對計算節點之間的所有資料包都落在瓶頸中的同一區域，這將導致網路卡佇列成為整個計算的瓶頸，並且效能受到影響。
例如，假設一對計算節點之間有數千個流（flows）。理想情況下，我們希望將流平衡分佈在所有的核心上，以便可以由不同的CPU將其拾取，以進行資料包處理。但是對於MPLSoGRE，已知埠的資訊沒有足夠的熵，來自特定計算節點的所有資料包都會發生，即使有很多流量，網路卡也不會將它們分發到所有佇列。因此，這裡不再像我們所知道的那樣，實際上資料包不會像這樣分散在多個核心中，它只會分配給一個核心。
因此，儘管有很多CPU核心，但由於所有資料包必須經過C1，C1本質上成為了瓶頸。資料包無法直接流經C2、C3、C4，是因為它們沒有在硬體上載入，所有其它核心必須從C1獲取資料包，顯然C1將會過載。
我們為Tungsten Fabric資料平面引入了一項新功能，該功能消除了MPLSoGRE資料包的瓶頸，使得效能與CPU核心數成正比。這意味著沒有單個CPU核心會成為瓶頸，並且網路卡硬體將資料包平均分配給所有CPU核心。
我們的解決方案由Intel DDP（dynamic device personalization）技術提供支援，使用乙太網700系列的產品來提供。英特爾轉向可程式設計管線模型後，確保它們引入了諸如韌體可升級之類的功能，DDP允許在執行時動態重新配置網路卡中的資料包處理管道，而無需重啟伺服器。軟體可以將自定義配置檔案應用到網路卡，我們可以將這些配置檔案視為附件，可以由終端使用者自己構建。這些配置檔案可以透過軟體重新整理到網路卡上，以便它們可以開始線上識別和分類新的資料包型別，並將這些資料包分配到不同的Rx佇列。
這是MPLSoGRE實施的情況，首先是這是一個沒有DDP提取功能的MPLSoGRE資料包，它沒有獲得在當前資料包中聽到的內部實際存在的啟動資訊，因此它沒有足夠的資訊來正確分配資料包。在第二個圖例中啟用了DDP，配置檔案便可以開始識別內部資料包標頭，以及內部IP標頭和內部UDP標頭，因此它可以開始使用該資訊來計算雜湊。
如何使DDP成為終端使用者需要為其資料包型別建立配置檔案的方式？
可以透過使用Intel的配置檔案編輯器（profile editor）工具來建立，Intel在其上釋出了一些標準配置檔案，可以直接從Intel網站下載。配置檔案編輯器可用於建立新條目，或者修改分析器的現有條目，這是第1步。第2步，為MPLSoGRE資料包建立一個新的配置檔案，該配置檔案在不同的層上定義資料包頭的結構。第3步，是編譯並建立一個二進位制程式包，可以應用於網路卡。第4步，我們可以使用DPDK API在每個工具介面將這些配置檔案載入到網路卡。接下來第5步，網路卡就能夠識別MPLSoGRE資料包。
接下來，我們需要測試並確認，DDP可以提供幫助帶來效能提升。
首先，我們的測試框架廣泛用於開發和測試vRouter。我們使用代理方式以擁有快速概念驗證的能力，並收集資訊。測試vRouter效能的所有方法，包括封裝和計算節點之間的封裝，並且總是會包含overlay網路，就像在圖例中的所看到的那樣，我們透過第三個物件（rapid jump VM），該物件只有控制流量（不透過其它任何流量），向VM傳送指令並收集資訊。為了實現測試目標，我們採用丟包率只有0.001％的二進位制搜尋，使用標準的測試框架和規範。
在vRouter中，我們可以找到指令碼，顯示每個核心CPU資料包處理的統計資訊，以證明網路卡正確地集中了所有核心之間的流量。這些統計資訊來自VM0介面，這意味著連線與物理網路卡之間的介面。
在左側，你可以看到核心1沒有在處理軟體包，這實際上意味著該核心未接收到任何由vRouter處理的軟體包。此核心只是忙於輪詢程式包，並在vRouter上的其它可用核心之間分配程式包。這意味著vRouter將成為瓶頸，因為首先需要將所有進入vRouter的流量從網路卡佇列中拉出，然後將其進行重新分配（跨其它核心）以轉發到VM。
而在右側，你可以看到使用DDP的網路卡已經正確分配了流量，Rx佇列中所有核心之間的流量幾乎相等。證明網路卡完成了自己工作，並平均分配了流量。
可以看到，是否使用DDP，在效能結果中統計資料上的差別。在不大於3個核心的情況下，使用DDP並沒有得到任何好處——因為對於輪詢核心和跨核心重新分配流量，目前網路卡處理這樣的佇列還是足夠快的。
但是一旦增加核心數量，然後提高整體效能，那麼網路卡就成為了瓶頸——在沒有DDP的情況下效能不會提高，即使增加了核心數也是如此，因為總有一個核心在拉動流量，並且你可以看到，在沒有DDP的部分中6.5mpps左右是一個核心從網路卡佇列中輪詢的最大值。
隨著核心的數量增加，每個核心都從網路卡接收了相同數量的流量。一旦核心數量超過6個，則收益將變得更高。正如我們所看到的，具有6個核心的增益大約為73％，這確實是個很酷的數字。不僅可以提高效能，使用DDP還可以得到更好的降低延遲。這是因為我們不需要平衡核心之間的流量，也不需要計算每個資料包的雜湊值。在vRouter上，這將由網路卡完成，收益的增加平均為40％，最多為80％，這已經是非常棒的數字了
。
綜上，對於擁有多個核心的用例，我們可以藉助DDP技術獲得很大的收益。另外，對於5G用例而言，DDP能夠減少延遲這一點非常重要。在所有我們希望使用MPLSoGRE情況下，藉助vRouter，我們已經準備好在多核中進行5G應用部署。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69981760/viewspace-2718176/，如需轉載，請註明出處，否則將追究法律責任。
