異數OS TCP協議棧測試（四）–網絡卡適配篇

本文來自異數OS社群

github： https://github.com/yds086/HereticOS
異數OS社群QQ群： 652455784
異數OS-織夢師（訊息中介軟體）群： 476260389

為了實際走向應用，異數OS目前適配了netmap平臺，DPDK平臺，暫時每埠單核單佇列的模式，後面各項問題解決後，開始適配RSS FDIR方案，下面是目前適配各個網絡卡驅動平臺的測試結果。

測試說明

測試硬體平臺

CPU ： E5 2670 V1 2.3G
記憶體：64G
網絡卡： intel 82599 雙口，5GT PCI E限制（損失30%滿載收發包效能）

測試用例

1.雙口雙核，將網絡卡兩個口用光纖迴環連結，CPU3 建立TCP server,CPU 5建立 指定連線數量的TCP Client執行緒（每連結4執行緒），測試方案使用 異數OS TCP協議棧測試（三）–長連線篇的的測試方法，成績是ECHO的iops成績。

1.單口單核，將網絡卡1個口的TX RX光纖迴環連結，CPU3 建立TCP server,同時建立 指定連線數量的TCP Client執行緒，測試方案使用 異數OS TCP協議棧測試（三）–長連線篇的的測試方法，成績是ECHO的iops成績。

3.UDP NIC迴環，分別在雙口雙核 單口單核模式下，建立兩個執行緒，兩個執行緒繫結對應的網絡卡介面卡，對發UDP包記錄下收發包的速度，成績是收包發包迴圈的次數，一次收一個發把一個包。

測試結果

適配總結

netmap，dpdk，異數OS軟體交換機測試對比

通過適配netmap和DPDK平臺，總結一些問題，netmap適配下來，效能比DPDK要強大概10%到100%，尤其是在連結多，app業務佔用記憶體多的環境，dpdk在3W連結以上會出現Server端RX丟包(Dropped)，導致連結大量的丟失，600W丟失500w，並造成不穩定，而這一現象目前在netmap環境下沒有出現，netmap以及異數OS軟體交換機可以做到600W 0丟包，另外netmap由於採用ring與上層協議棧交換資料，不需要分配釋放包快取，因此降低了適配複雜度，並提高了包交換效能，這使得netmap的效能可以達到異數OS軟體交換機效能的90%，而DPDK只能交換包陣列，需要大量的工作做包快取管理，效率較低，這可能是DPDK實際上比netmap以及異數OS軟體交換機慢的原因。

TCP協議棧適配網絡卡的問題

由於TCP需要類似ECHO的傳輸流程控制機制，因此單個連結並不能批量收發包，這導致使用批量收發包技術的網絡卡出現效能損失，效能被網絡卡約束所影響，出現了一個性能牆，由測試資料來看，必須在32或者64路以上併發TCP連結，才有希望利用10G網絡卡的IO能力，由於異數OS軟體交換機使用記憶體交換技術（多核採用CPU cache跨核交換），因此延遲比較低，一般在70ns左右，因此不存在單鏈接效能牆的問題。

DPDK丟包問題分析

DPDK經過反覆分析調參,任然無法解決丟包的問題，在3W連結以下以及UDP收發包測試中，DPDK可以0丟包，推斷可能是需要設定網絡卡流控，但實際上設定後並沒有任何效果，排除流控的問題，無奈用異數OS做了軟體流控，將TCP客戶端發包能力控制在5000以內,發現丟包問題任然無法解決，而異數OS此時對rte_eth_rx_burst的polling速度是30M，所以排除是協議棧延遲高的問題，經過慢速持續增長的連結執行緒觀察（每秒建立1000個TCPClient，netmap平臺可每秒建立200W連結無問題）,在Client連結執行緒數建立超過3W時，丟包現象開始發生，此時軟體層佔用巨頁記憶體20M，正好達到E52670 L3 Cache的尺寸，所以暫時推斷DPDK的ddio的ring polling技術可能存在問題，當l3 cache不足，需要在記憶體交換包時可能出現丟包。