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