深入淺出DPDK學習筆記——前言

肥叔菌發表於2020-11-03

多核

2005年的夏天, 剛加入Intel的我們暢想著CPU多核時代的到來給軟體業帶來的挑戰與機會。 如果要充分利用多核處理器, 需要軟體針對並行化做大量改進, 傳統軟體的並行化程度不高, 在多核以前, 軟體依靠CPU頻率提升自動獲得更高效能。 並行化改進不是一件簡單的工作, 許多軟體需要重新設計, 基本很難在短期實現, 整個計算機行業都對此糾結了很久。 2005年以前, 整個CPU的發展歷史, 是不斷提升晶片運算頻率核心的做法, 軟體效能會隨著處理器的頻率升高, 即使軟體不做改動, 效能也會跟著上一個臺階, 但這樣的邏輯進入多核時代已無法實現。 在過去10年裡, 伺服器平臺的處理器核心數目擴充套件了很多。 英特爾至強系列的處理器的主要面向雙通道(雙路) 伺服器和相應的硬體平臺。與此同時, 基於MIPS、 Power、 ARM架構的處理器也經歷著類似或者更加激進的並行化計算的路線圖。 在處理器飛速發展的同時, 伺服器平臺在硬體技術上提供了支撐。 基於PCI Express的高速IO裝置、 記憶體訪問與頻寬的上升相輔相成。 此外, 價格和經濟性優勢越發突出, 今天一臺雙路伺服器的價格可能和10年前一臺高階膝上型電腦的價格類似, 但計算能力達到甚至超越了當年的超級計算機。 強大的硬體平臺為軟體優化技術創新蘊蓄了溫床。

乙太網介面技術也經歷了飛速發展。 從早期主流的10Mbit/s與100Mbit/s, 發展到千兆網(1Gbit/s) 。 到如今, 萬兆(10Gbit/s) 網路卡技術成為資料中心伺服器的主流介面技術, 近年來, Intel等公司還推出了40Gbit/s、 100Gbit/s的超高速網路介面技術。 而CPU的執行頻率基本停留在10年前的水平, 為了迎接超高速網路技術的挑戰, 軟體也需要大幅度創新。

結合硬體技術的發展, DPDK(Data Plane Development Kit) , 一個以軟體優化為主的資料面技術應時而生, 它為今天NFV技術的發展提供了絕佳的平臺可行性。

IXP

提到硬體平臺和資料面技術, 網路處理器是無法繞過的話題。 電信行業通常使用網路處理器或類似晶片技術作為資料面開發平臺首選。Intel此前也曾專注此領域, 2002年收購了DEC下屬的研究部門, 在美國馬薩諸塞州哈德遜開發了這一系列晶片, 誕生了行業聞名的IntelExchange Architecture Network Processor(IXP4xx、 IXP12xx、IXP24xx、 IXP28xx) 產品線, 曾取得行業市場佔有率第一的成績。 即使今日, 相信很多通訊業的朋友, 還對這些處理器晶片有些熟悉或者非
常瞭解。 IXP內部擁有大量的微引擎(MicroEngine) , 同時結合了XSCALE作為控制面處理器, 眾所周知, XSCALE是以ARM晶片為核心技術的一種擴充套件。

2006年, AMD向Intel發起了一場大戰, 時至今日結局已然明瞭,Intel依賴麾下的以色列團隊, 打出了新一代Core架構, 迅速在能效比上完成超車。 公司高層同時確立了Tick-Tock的研發節奏, 每隔兩年推出新一代體系結構, 每隔兩年推出基於新一代製造工藝的晶片。 這一戰略基本保證了每年都會推出新產品。 當時AMD的處理器技術一度具有領先地位, 並觸發了Intel在內部研發架構城門失火的狀況下不得不進行重組, 就在那時Intel的網路處理器業務被進行重估, 由於IXP晶片系列的市場容量不夠大, Intel的架構師也開始預測, 通用處理器多核路線有取代IXP專用處理晶片的潛力。 自此,IXP的研發體系開始調整, 逐步轉向使用Intel CPU多核的硬體平臺, 客觀上講, 這一轉型為DPDK的產生創造了機會。時至今日, Intel還保留並發展了基於硬體加速的QuickAssist技術, 這和當日的IXP息息相關。 由此看來, DPDK算是生於亂世。

DPDK的歷史

網路處理器能夠迅速將資料包文接收入系統, 比如將64位元組的報文以10Gbit/s的線速也就是14.88Mp/s(百萬報文每秒) 收入系統, 並且交由CPU處理, 這在早期Linux和伺服器平臺上無法實現。 以VenkyVenkastraen、 Walter Gilmore、 Mike Lynch為核心的Intel團隊開始了可行性研究, 並希望藉助軟體技術來實現, 很快他們取得了一定的技術突破, 設計了執行在Linux使用者態的網路卡程式架構。 傳統上, 網路卡驅動程式執行在Linux的核心態, 以中斷方式來喚醒系統處理, 這和歷史形成有關。 早期CPU執行速度遠高於外設訪問, 所以中斷處理方式十分有效, 但隨著晶片技術與高速網路介面技術的一日千里式發展, 報文吞吐需要高達10Gbit/s的埠處理能力, 市面上已經出現大量的25Gbit/s、40Gbit/s甚至100Gbit/s高速埠, 主流處理器的主頻仍停留在3GHz以下。 高階遊戲玩家可以將CPU超頻到5GHz, 但網路和通訊節點的設計基於能效比經濟性的考量, 網路裝置需要日以繼夜地執行, 執行成本(包含耗電量) 在總成本中需要重點考量, 系統選型時大多選取2.5GHz以下的晶片, 保證合適的價效比。 I/O超越CPU的執行速率, 是橫在行業面前的技術挑戰。 用輪詢來處理高速埠開始成為必然, 這構成了DPDK執行的基礎

在理論框架和核心技術取得一定突破後, Intel與6wind進行了合作, 交由在法國的軟體公司進行部分軟體開發和測試, 6wind向Intel交付了早期的DPDK軟體開發包。 2011年開始, 6wind、 Windriver、Tieto、 Radisys先後宣佈了對Intel DPDK的商業服務支援。 Intel起初只是將DPDK以原始碼方式分享給少量客戶, 作為評估IA平臺和硬體效能的軟體服務模組, 隨著時間推移與行業的大幅度接受, 2013年Intel將DPDK這一軟體以BSD開源方式分享在Intel的網站上, 供開發者免費下載。 2013年4月, 6wind聯合其他開發者成立www.dpdk.org的開源社群,DPDK開始走上開源的大道。

DPDK在程式碼開源後, 任何開發者都被允許通過www.dpdk.org提交程式碼。 隨著開發者社群進一步擴大, Intel持續加大了在開源社群的投入, 同時在NFV浪潮下, 越來越多的公司和個人開發者加入這一社群,比如Brocade、 Cisco、RedHat、 VMware、 IBM, 他們不再只是DPDK的消費者, 角色向生產者轉變, 開始提供程式碼, 對DPDK的程式碼進行優化和整理。 起初DPDK完全專注於Intel的伺服器平臺技術, 專注於利用處理器與晶片組高階特性, 支援Intel的網路卡產品線系列。DPDK 2.1版本在2015年8月釋出, 幾乎所有行業主流的網路卡裝置商都已經加入DPDK社群, 提供原始碼級別支援。 另外, 除了支援通用網路卡之外, 能否將DPDK應用在特別的加速晶片上是一個有趣的話題, 有很多工作在進行中, Intel最新提交了用於Crypto裝置的介面設計, 可以利用類似Intel的QuickAssit的硬體加速單元, 實現一個針對資料包加解密與壓縮處理的軟體介面。

在多架構支援方面, DPDK社群也取得了很大的進展, IBM中國研究院的祝超博士啟動了將DPDK移植到Power體系架構的工作, Freescale的中國開發者也參與修改, Tilera與Ezchip的工程師也花了不少精力將DPDK執行在Tile架構下。 很快, DPDK從單一的基於Intel平臺的軟體,逐步演變成一個相對完整的生態系統, 覆蓋了多個處理器、 乙太網和硬體加速技術。
在Linux社群融合方面, DPDK也開始和一些主流的Linux社群合作, 並得到了越來越多的響應。 作為Linux社群最主要的貢獻者之一的RedHat嘗試在Fedora Linux整合DPDK; 接著RedHat Enterprise Linux在安裝庫裡也加入DPDK支援, 使用者可以自動下載安裝DPDK擴充套件庫。RedHat工程師還嘗試將DPDK與Container整合測試, 並公開發布了執行結果。 傳統虛擬化的領導者VMware的工程師也加入DPDK社群, 負責VMXNET3-PMD模組的維護。 Canonical在Ubuntu 15中加入了DPDK的支援。

由於DPDK主體執行在使用者態, 這種設計理念給Linux或者FreeBSD這類作業系統帶來很多創新思路, 也在Linux社群引發一些討論。DPDK的出現使人們開始思考, Linux的使用者態和核心態, 誰更適合進行高速網路資料包文處理。 從簡單資料對比來看, 在Intel的通用伺服器上, 使用單核處理小包收發, 純粹的報文收發, 理想模型下能達到大約57Mp/s(每秒百萬包) 。 儘管在真實應用中, 不會只收發報文不處理, 但這樣的效能相對Linux的普通網路卡驅動來說已經是遙不可及的高效能。 OpenVSwitch是一個很好的例子, 作為主流的虛擬交換開源軟體, 也嘗試用DPDK來構建和加速虛擬交換技術, DPDK的支援在OVS2.4中被髮布, 開闢了在核心態資料通道之外一條新的使用者態資料通道。 目前, 經過20多年的發展, Linux已經累積大量的開源軟體, 具備豐富的協議和應用支援, 無所不能, 而資料包文進出Linux系統, 基本都是在Linux核心態來完成處理。 因為Linux系統豐富強大的功能, 相當多的生產系統(現有軟體) 執行在Linux核心態, 這樣的好處是大量軟體可以重用, 研發成本低。 但也正因為核心功能強大豐富, 其處理效率和效能就必然要做出一些犧牲。

相關文章