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