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