引言：最近在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项目交流群的二维码。