引言：最近在FAST开源项目群中对2016 SIGCOMM论文(wén)ClickNP进行了讨论，我们总结了五个问题。我们与ClickNP的第一作者李博杰进行了沟通和讨论，在此对博杰表示感謝(xiè)。下面把关于ClickNP的五个问题和博杰的回复向大家分(fēn)享一下，希望大家能(néng)有(yǒu)所收获，并多(duō)多(duō)发表意见。      问题一：FPGA在数据中心交换中大有(yǒu)可(kě)為(wèi)。随着多(duō)核处理(lǐ)器能(néng)力提升（特别是核数提升），数据中心端系统连接网络的第一跳交换机已经逐渐由外部TOR交换机迁移到服務(wù)器内部的OVS交换机，一些复杂的网络处理(lǐ)功能(néng)也由TOR上实现转移到OVS上实现。由于OVS性能(néng)受限，在网卡上对交换进行加速是趋势。ClickNP研究的点十分(fēn)关键，实现的各种网络功能(néng)对于第一跳交换机来说也十分(fēn)关键，因此研究的意义很(hěn)重要。而数据中心网络中协议发展很(hěn)快，使用(yòng)FPGA来实现对这些协议的处理(lǐ)十分(fēn)合适，通过FPGA逻辑的重构可(kě)以支持各种新(xīn)的，甚至是未来出现的协议。      另外，随着OVS/FPGA成為(wèi)第一跳交换机，因此TOR交换机已经逐渐变成汇聚交换机的角色，对TOR交换机的编程（如利用(yòng)p4）意义可(kě)能(néng)已经不大。因此个人感觉类似Barefoot的可(kě)编程芯片在数据中心中不一定有(yǒu)很(hěn)好的发展前景，因為(wèi)TOR和其他(tā)汇聚交换机以及核心交换机只需要简单和快速即可(kě)。      博杰回复：我和你们的观点一致，微软的策略也是在端上而非网络里实现网络功能(néng)。网络就做三层路由，因為(wèi)微软跟Intel是同盟嘛。然而其他(tā)公司不一定这么想，比如Google跟Cisco是同盟，他(tā)们比较想把复杂性放在网络里面，这时可(kě)编程交换机就有(yǒu)用(yòng)了。在现实中，这两种方案我认為(wèi)不是对立的，比如微软数据中心在端上用(yòng)FPGA做NFV，又(yòu)在网络里用(yòng)可(kě)编程交换机(Azure cloud switch,Broadcom trident II)做灵活的Scheduling和负载均衡器的Data path offloading。      问题二：HLS/OpenCL面向的用(yòng)户群體(tǐ)应该是各种应用(yòng)开发人员，用(yòng)于面向应用(yòng)算法加速，（如神经网络算法处理(lǐ)加速，基因计算加速等等）。而这些完全人没有(yǒu)也不需要掌握底层FPGA结构和编程的知识。而网络设备研制是网络设备制造商(shāng)专业开发人员负责，因此应该使用(yòng)Verilog等寄存器传输级的硬件描述语言开发，以追求更高的性能(néng)和更低的功耗。论文(wén)用(yòng)HLS/OpenCL来设计几乎标准的，功能(néng)变化频率很(hěn)低的网络设备，应该是没有(yǒu)必要，现实中也是没有(yǒu)需求的。      博杰回复：在传统数据中心网络中也许网络功能(néng)相对固定，但在云数据中心中网络功能(néng)经常变化，这也是各大云服務(wù)商(shāng)使用(yòng)虚拟化网络功能(néng)的原因。比如流表的Match和Action、压缩算法、负载均衡策略、数据包调度策略、RoCE等传输协议，都是不断演进的。我们使用(yòng)FPGA也是為(wèi)了兼具灵活性和性能(néng)，解决CPU做网络功能(néng)的性能(néng)瓶颈。      您说的用(yòng)HLS/OpenCL没有(yǒu)必要，这一点微软产品部分(fēn)也是认同的。因此ClickNP目前只是研究部门在用(yòng)。产品部门有(yǒu)专业的硬件工程师写Verilog，部署规模那么大，用(yòng)Verilog写出来的代码资源占用(yòng)明显少于HLS生成的（ClickNP论文(wén)中也有(yǒu)比较），因此他(tā)们选择了Verilog路線(xiàn)。      问题三：关于性能(néng)评测的方法有(yǒu)些看不懂，例如表2中，LPM_tree逻辑最大频率為(wèi)221.8MHz，最大的性能(néng)也是221.8MPPS，而Hash_TCAM的最大频率和性能(néng)值也是一致的，这说明这不是一个测试结果，而是人為(wèi)的认為(wèi)通过流水就可(kě)以让每个时钟周期出一个结果？这种估计太乐观了吧。例如一次LPM查表需要n次访存，必须完全实现n级流水線(xiàn)才能(néng)现实中是很(hěn)难实现的。      博杰回复：ClickNP中所有(yǒu)的Element都是完全流水的，用(yòng)HLS的说法是II=1。这也是HLS相比Verilog编程的一种优势。Verilog写流水線(xiàn)费时费力，而且不知道能(néng)把多(duō)少个组合逻辑运算合并到一个时钟周期中。HLS工具则可(kě)以根据逻辑延迟估算一个时钟周期能(néng)做多(duō)少事，自动排好流水，所生成的Verilog代码不仅不会浪费硬件资源，而且能(néng)在流水深度（延迟）和时钟频率间取得平衡，更不用(yòng)说开发效率的差别了。      问题四：作者使用(yòng)的BRAM TCAM的实现，应该是把FPGA的逻辑单元用(yòng)作64*1的寄存器使用(yòng)，难道不是用(yòng)Verilog等寄存器传输级语言编程+相关的综合约束实现的，也是由HLS综合实现的吗？HLS这么强，这个有(yǒu)点颠覆我的认识了。      博杰回复：BRAM TCAM的实现是Xilinx的一篇论文(wén)里提出的，基本思路是把一个较長(cháng)的匹配拆分(fēn)成多(duō)个较短的匹配，然后对每个n位的短匹配预先计算出所有(yǒu)可(kě)能(néng)（2的n次方），直接查表。       ClickNP论文(wén)里提到的Element都是用(yòng)C语言编写，HLS工具编译出来的。我承认在HLS里面实现涉及到Memory的处理(lǐ)比较麻烦，因此访存有(yǒu)延迟，HLS工具只会根据最差的可(kě)能(néng)安排Pipeline，然而硬件工程师可(kě)以合理(lǐ)安排这些访存，这使得它们之间不存在冲突。解决访存依赖就是编译器的一种优化。当然还有(yǒu)其他(tā)类型的手工优化，但没有(yǒu)写进论文(wén)，因為(wèi)这些优化是针对HLS编译器特性的，而不具有(yǒu)普适性。      问题五：作者在今年SIGCOMM综述和ClickNP论文(wén)撰写體(tǐ)会中，着重提出的软件Element和硬件Element协同处理(lǐ)的问题在论文(wén)中描述不充分(fēn)？是篇幅原因？个人感觉这个应该写详细一些，而4.2.1中对访存依赖的描述应该不是很(hěn)重要（抱歉，可(kě)能(néng)没有(yǒu)理(lǐ)解作者用(yòng)意），因為(wèi)对于寄存器传输级的编程来说，这个问题不存在，只有(yǒu)使用(yòng)HLS才有(yǒu)这个问题，而个人感觉HLS不是NF实现应该使用(yòng)的方法（第二点已经指出）。      博杰回复：在软硬件协同处理(lǐ)方面我们的例子确实不太充分(fēn)，只有(yǒu)一个PacketCapture和一个L4 Loadbalancer。不过这一部分(fēn)没有(yǒu)太多(duō)东西可(kě)说，就是把复杂的部分(fēn)通过PCIE channel发到CPU，处理(lǐ)之后再通过PCIE channel发回去。编译器并不能(néng)自动做软硬件之间的切割。      PS：欢迎大家关注FAST公众号，并对我们提出的话题发表更多(duō)的观点，同时我们会向大家推送FAST的最新(xīn)成果和相关资料。      我们创建了一个FAST项目交流群，欢迎大家加入和众多(duō)老师专家一起讨论网络交换方面的问题，下面是FAST项目交流群的二维码。