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