本文转载自：FPGA的现今未微信公众号
注：本文由作者授权转发，如需转载请联系作者本人
用FPGA来做硬件加速，也有十年的时间了，最近我在回顾这些年的项目经历时，突然有了一个想法，用FPGA做硬件加速是否是一条正确的路？这个问题我想不会有统一的答案，不同的人，不同的平台，不同的公司都会有不同的结论。总体来说，硬件加速也经历了好几个阶段吧。
第一阶段：按明确需求做
最早在平台部门第一次用FPGA做加速，是09年给核心网产品线做计费的加速，具体用到的技术就是正则匹配。当时公司核心网产品性能不如友商，所以希望通过FPGA来做正则匹配和流表的处理。那加速到底能带来多少价值？当时也是产品第一次尝试，用的CPU还是MIPS芯片，软件和FPGA方案同时开发。产品做了非常充分的前期分析，给出了需求规格，到我们平台部门就是非常明确的需求了，项目价值方面需要考虑的就少了。所以衡量正则匹配的好坏，对于当时的我们来说就是性能了。
正则的性能如何衡量？涉及到好几个点，比如支持的总体流量是多少Gbps，在10%的报文头域需要做正则匹配的时候的匹配性能是多少，支持的TCP重排的性能是多少，支持的规则数是多少等等。好在这些指标当时都有明确的场景和需求，实现相对来说就简单多了。最终，产品的性能相比友商提升了2倍，部门拿了很多奖，也慢慢开始发展壮大。
这个阶段能成功的原因，回过头来看：就是软硬件设计一体化，即软件在设计之初就考虑了FPGA来做硬件加速，在架构上充分利用了硬件的能力。
第二阶段：性能摸高
有了一次成功的硬件加速经历后，开始思考把FPGA的加速能力用在其他的业务场景下，这是FPGA“被动加速”到“主动加速”的一个转折点。13年和Y产品线合作，帮他们做一个大数据的排序的加速，对当时的需求还记得很清楚：就是在1s内至少完成100M个32bit数据的排序，性能越高越好。为什么会提出这样的需求呢？因为在当时的场景下，大家对FPGA加速的理解都不是很深刻，只知道越快肯定是对业务加速是没有坏处的。后来我我们通过不断地优化FPGA的方案，做到了100M个32bit的数据排序只需要0.6s+的样子。相比软件提升了很多很多倍了。
那问题来了，FPGA能做到这么快对产品有什么价值呢？按照现在的思路应该是要进行端到端的性能测试看看对产品性能的提升。很可惜，当时没有走到这一步。
后来做压缩也是一样，当时负责压缩业务的拓展，思考的是如何做出有竞争力的压缩产品。衡量压缩无非就是2个指标，性能和压缩率。就压缩算法本身而言，硬件相比软件在压缩率方面是很难有优势，除非在压缩前对数据做一些预处理。FPGA的加速主要是在性能上发力，通过多字节的hash、跳跃查找、多核并行等关键技术来提升性能。这里追求的都是在不损失压缩率的情况下，如何把性能做得更高。在后面很长的一段时间里，都朝这个性能摸高的目标前进。
直到后来部分IP用在芯片上，我们发现性能高并不一定是有用的，关键是看产品端到端的性能是否有提升。
第三阶段：端到端性能提升
13年给核心网提供的版本在测试过程中发现软件的性能不够。因为FPGA主要负责提升软件性能，所以第一时间就考虑到是不是FPGA性能没有做好？后来通过定位，发现FPGA没有“吃饱”。比如FPGA的性能是20Gbps，但是软件给不了这么多数据。进一步分析发现FPGA实现的这一部分功能在整个软件处理流程中所消耗的CPU是非常少的，即使这部分软件不做了，对性能的提升也是很有限的。
多次业务拓展失败经验后，团队逐渐明白，硬件加速不是性能越高越好，还要看加速的部分在整个系统中的比重情况，如果太小，这个点加速就没有意义了。
回到上面说的压缩项目，在当时经验的积累上，后续的投入不再盲目追求性能。比如某芯片项目，需要一个压缩IP，我们和软件一起论证了压缩在某个场景下的比重，以及满足需求所需要的性能、资源。最后交付的项目端到端的性能提升效果满足了产品的要求。
到这个阶段，才算稍微系统性的认识到了硬件加速的本质，单纯的FPGA性能提升不一定会给系统带来价值，需要在软件系统中端到端的衡量性能的提升。
第四阶段：主动优化
前期FPGA的加速取得一点点成绩后，我们开始思考一个问题就是如何让FPGA在硬件加速这个领域取得更多的成果？无疑就是寻找更多的业务场景。当怀疑到一个场景可能有加速的需求后，很自然的就进入了主动优化业务性能的阶段，如何主动优化呢？根据笔者的经验，这里总结为4个步骤。
定方向：所谓定方向，就是要明确一个突破口，比如从业务的层面看，问题往往是一个性能问题，或者单核处理大象流的问题，或者是CPU资源消耗过多的问题。硬件加速能否解决这些问题，此刻是不清楚的，但重点是能提出这个问题，指出优化的方向。
测现状：根据确定的方向，需要对业务系统进行测试，收集各种测试数据，确定问题的存在以及问题存在的原因。同时在找到加速点后，需要测试来确认性能可能提升的情况，确定加速的价值在哪里。
找原因：测现状和找原因往往是一个反复迭代的过程，比如通过分析测试数据，确定某个步骤是问题出现的关键步骤，那拿掉这个步骤后，问题是否解决？这需要继续测试，因为你可能会发现新的问题。还有就是整个系统可能并没有所谓的关键步骤，可能你需要找TOP3或者TOP5，打包成一个整体方案来做优化。
定方案：通过上述2个步骤的迭代，找到影响问题的原因后，问题就解决了一半，定方案这个步骤主要完成3个事情，第一是如何打通软硬件之间的处理流程，即要确定软件修改的方案；第二就是软硬件之间数据交付的方式；第三就是硬件的需求和规格。
此时此刻，在硬件加速的道路上似乎找到了2个通用的法则。（一）就是软硬件设计一体化架构，即软件在设计之初就考虑了FPGA来做硬件加速，充分利用了硬件的能力。（二）通过定方向、测现状、找原因、定方案这一套方法，寻找软件优化点。那还有没有其他的状况呢？
第五阶段：硬件加速是可行之路吗？
讨论一种业务场景，如下图所示，在一个机房中，通过交换机将网络数据以负载均衡的方式发送给各个服务器；每台服务器上部署了很多用户的任务，每个任务都会对网络数据的全部或者部分进行处理。假定其中一个任务是正则表达式的处理，我们知道，正则表达式是非常消耗资源的，纯软件方案需要消耗的核数较多，或者说性能做不上去。那在这种场景下如何做加速？
首先想到的就是在服务器上插加速卡，一来方案简单，二来对机房原有网络的改动也比较小。这种方案也有非常明显的缺点，一台服务器上有多个用户需要使用正则，但是规则的内容和大小、报文流量的大小（有的任务处理全部流量，有的任务处理部分流量）都不相同，正则的处理对每个用户来说也就完全不一样。即无法在同一张卡上实现不同规则，不同流量的正则匹配。即使采用部分重加载技术，需要对每个报文基于不同用户做多次匹配，这个性能可想而知。
另外就是采用集群的方式，如下图所示，FPGA服务器和通用服务器位置是等价的。在通用服务器上有业务需要的时候，通过机房内部的网络将任务传给FPGA服务器进行处理，处理完成后再返回给通用服务器。这种集群的方式的优点就是最大化的利用好硬件的性能，但是缺点也是显而易见，软件的改动比较大，网络的带宽可能也需要升级，还有就是数据中心的网络拓扑结构甚至都需要变动……
似乎又回到了开始的话题，如果不是软硬件协同进行，这种方案对原来的业务来说也是一次巨大的改动。推行的难度不仅仅取决于技术的复杂度，可能还取决于组织。涉及到组织的问题，就会想硬件加速到底能带来什么？硬件加速，在数据中心或者说互联网企业，会是一条正确的道路吗？
关于FPGA的硬件加速，你有什么心得或者体会，欢迎留言交流讨论，看看能否碰撞出一些新的火花。
