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