引言：最近在FAST開源項目群中對2016 SIGCOMM論文ClickNP進行(xíng)了讨論，我們總結了五個問題。我們與ClickNP的(de)第一(yī)作者李博傑進行(xíng)了溝通和(hé)讨論，在此對博傑表示感謝。下面把關于ClickNP的(de)五個問題和(hé)博傑的(de)回複向大家分享一(yī)下，希望大家能有(yǒu)所收獲，并多多發表意見。
問題一(yī)：FPGA在數據中心交換中大有(yǒu)可(kě)為(wèi)。随着多核處理(lǐ)器能力提升（特别是核數提升），數據中心端系統連接網絡的(de)第一(yī)跳交換機(jī)已經逐漸由外部TOR交換機(jī)遷移到服務器內(nèi)部的(de)OVS交換機(jī)，一(yī)些複雜的(de)網絡處理(lǐ)功能也由TOR上實現轉移到OVS上實現。由于OVS性能受限，在網卡上對交換進行(xíng)加速是趨勢。ClickNP研究的(de)點十分關鍵，實現的(de)各種網絡功能對于第一(yī)跳交換機(jī)來說也十分關鍵，因此研究的(de)意義很重要。而數據中心網絡中協議發展很快，使用FPGA來實現對這些協議的(de)處理(lǐ)十分合适，通過FPGA邏輯的(de)重構可(kě)以支持各種新的(de)，甚至是未來出現的(de)協議。
另外，随着OVS/FPGA成為(wèi)第一(yī)跳交換機(jī)，因此TOR交換機(jī)已經逐漸變成彙聚交換機(jī)的(de)角色，對TOR交換機(jī)的(de)編程（如(rú)利用p4）意義可(kě)能已經不大。因此個人感覺類似Barefoot的(de)可(kě)編程芯片在數據中心中不一(yī)定有(yǒu)很好的(de)發展前景，因為(wèi)TOR和(hé)其他彙聚交換機(jī)以及核心交換機(jī)隻需要簡單和(hé)快速即可(kě)。
博傑回複：我和(hé)你們的(de)觀點一(yī)緻，微軟的(de)策略也是在端上而非網絡裏實現網絡功能。網絡就做(zuò)三層路由，因為(wèi)微軟跟Intel是同盟嘛。然而其他公司不一(yī)定這麽想，比如(rú)Google跟Cisco是同盟，他們比較想把複雜性放在網絡裏面，這時可(kě)編程交換機(jī)就有(yǒu)用了。在現實中，這兩種方案我認為(wèi)不是對立的(de)，比如(rú)微軟數據中心在端上用FPGA做(zuò)NFV，又在網絡裏用可(kě)編程交換機(jī)(Azure cloud switch,Broadcom trident II)做(zuò)靈活的(de)Scheduling和(hé)負載均衡器的(de)Data path offloading。
問題二：HLS/OpenCL面向的(de)用戶群體應該是各種應用開發人員，用于面向應用算法加速，（如(rú)神經網絡算法處理(lǐ)加速，基因計算加速等等）。而這些完全人沒有(yǒu)也不需要掌握底層FPGA結構和(hé)編程的(de)知識。而網絡設備研制是網絡設備制造商(shāng)專業開發人員負責，因此應該使用Verilog等寄存器傳輸級的(de)硬件描述語言開發，以追求更高(gāo)的(de)性能和(hé)更低(dī)的(de)功耗。論文用HLS/OpenCL來設計幾乎标準的(de)，功能變化頻率很低(dī)的(de)網絡設備，應該是沒有(yǒu)必要，現實中也是沒有(yǒu)需求的(de)。
博傑回複：在傳統數據中心網絡中也許網絡功能相對固定，但在雲數據中心中網絡功能經常變化，這也是各大雲服務商(shāng)使用虛拟化網絡功能的(de)原因。比如(rú)流表的(de)Match和(hé)Action、壓縮算法、負載均衡策略、數據包調度策略、RoCE等傳輸協議，都是不斷演進的(de)。我們使用FPGA也是為(wèi)了兼具靈活性和(hé)性能，解決CPU做(zuò)網絡功能的(de)性能瓶頸。
您說的(de)用HLS/OpenCL沒有(yǒu)必要，這一(yī)點微軟産品部分也是認同的(de)。因此ClickNP目前隻是研究部門在用。産品部門有(yǒu)專業的(de)硬件工程師寫Verilog，部署規模那麽大，用Verilog寫出來的(de)代碼資源占用明顯少于HLS生成的(de)（ClickNP論文中也有(yǒu)比較），因此他們選擇了Verilog路線。
問題三：關于性能評測的(de)方法有(yǒu)些看不懂，例如(rú)表2中，LPM_tree邏輯最大頻率為(wèi)221.8MHz，最大的(de)性能也是221.8MPPS，而Hash_TCAM的(de)最大頻率和(hé)性能值也是一(yī)緻的(de)，這說明這不是一(yī)個測試結果，而是人為(wèi)的(de)認為(wèi)通過流水就可(kě)以讓每個時鍾周期出一(yī)個結果？這種估計太樂(yuè)觀了吧(ba)。例如(rú)一(yī)次LPM查表需要n次訪存，必須完全實現n級流水線才能現實中是很難實現的(de)。
博傑回複：ClickNP中所有(yǒu)的(de)Element都是完全流水的(de)，用HLS的(de)說法是II=1。這也是HLS相比Verilog編程的(de)一(yī)種優勢。Verilog寫流水線費時費力，而且不知道(dào)能把多少個組合邏輯運算合并到一(yī)個時鍾周期中。HLS工具則可(kě)以根據邏輯延遲估算一(yī)個時鍾周期能做(zuò)多少事，自(zì)動排好流水，所生成的(de)Verilog代碼不僅不會浪費硬件資源，而且能在流水深度（延遲）和(hé)時鍾頻率間取得平衡，更不用說開發效率的(de)差别了。
問題四：作者使用的(de)BRAM TCAM的(de)實現，應該是把FPGA的(de)邏輯單元用作64*1的(de)寄存器使用，難道(dào)不是用Verilog等寄存器傳輸級語言編程+相關的(de)綜合約束實現的(de)，也是由HLS綜合實現的(de)嗎？HLS這麽強，這個有(yǒu)點颠覆我的(de)認識了。
博傑回複：BRAM TCAM的(de)實現是Xilinx的(de)一(yī)篇論文裏提出的(de)，基本思路是把一(yī)個較長(cháng)的(de)匹配拆分成多個較短(duǎn)的(de)匹配，然後對每個n位的(de)短(duǎn)匹配預先計算出所有(yǒu)可(kě)能（2的(de)n次方），直接查表。
ClickNP論文裏提到的(de)Element都是用C語言編寫，HLS工具編譯出來的(de)。我承認在HLS裏面實現涉及到Memory的(de)處理(lǐ)比較麻煩，因此訪存有(yǒu)延遲，HLS工具隻會根據最差的(de)可(kě)能安排Pipeline，然而硬件工程師可(kě)以合理(lǐ)安排這些訪存，這使得它們之間不存在沖突。解決訪存依賴就是編譯器的(de)一(yī)種優化。當然還有(yǒu)其他類型的(de)手工優化，但沒有(yǒu)寫進論文，因為(wèi)這些優化是針對HLS編譯器特性的(de)，而不具有(yǒu)普适性。
問題五：作者在今年(nián)SIGCOMM綜述和(hé)ClickNP論文撰寫體會中，着重提出的(de)軟件Element和(hé)硬件Element協同處理(lǐ)的(de)問題在論文中描述不充分？是篇幅原因？個人感覺這個應該寫詳細一(yī)些，而4.2.1中對訪存依賴的(de)描述應該不是很重要（抱歉，可(kě)能沒有(yǒu)理(lǐ)解作者用意），因為(wèi)對于寄存器傳輸級的(de)編程來說，這個問題不存在，隻有(yǒu)使用HLS才有(yǒu)這個問題，而個人感覺HLS不是NF實現應該使用的(de)方法（第二點已經指出）。
博傑回複：在軟硬件協同處理(lǐ)方面我們的(de)例子(zǐ)确實不太充分，隻有(yǒu)一(yī)個PacketCapture和(hé)一(yī)個L4 Loadbalancer。不過這一(yī)部分沒有(yǒu)太多東西可(kě)說，就是把複雜的(de)部分通過PCIE channel發到CPU，處理(lǐ)之後再通過PCIE channel發回去(qù)。編譯器并不能自(zì)動做(zuò)軟硬件之間的(de)切割。
PS：歡迎大家關注FAST公衆号，并對我們提出的(de)話題發表更多的(de)觀點，同時我們會向大家推送FAST的(de)最新成果和(hé)相關資料。
我們創建了一(yī)個FAST項目交流群，歡迎大家加入和(hé)衆多老師專家一(yī)起讨論網絡交換方面的(de)問題，下面是FAST項目交流群的(de)二維碼。
