软硬件融合的痛点在哪?

关于软硬件融合，有一段话讲的非常不错：

Software when you can, hardware when you must. Whenever possible, compute, networking, and storage functions should be done in software where reasonable performance can be attained.

If you have to accelerate something, use the most generic and malleable compute engine or network ASIC that does the trick. This might mean sticking with a CPU or a GPU for certain functions, or even using an FPGA

从业很多年，无论是网络通信，还是金融高频交易，一直都是在软硬件融合的痛点上被硬件团队和软件团队按在地上摩擦… 结论就是两个团队有不可调和的矛盾，而这些矛盾就来自于相互的不理解。最简单的就是一个function call，从软件团队来看，自己CPU运行可能只需要200个cycles，但是offload给硬件，来回的同步调用延迟就大于200 cycles，这种情况下软件团队会倾向于就自己干了。在这个视角来看很多DPU的offload场景都是伪命题。

但是软件不得不去面对冯诺伊曼架构的瓶颈，然而在很多商用场合，内存的带宽并没有被用满，例如Google在Datacenter Tax中所描述的，数据中心大多数主机的内存带宽只用了30%。这个时候其实软件的工程师以为可以通过算法加到70%以上，但是很遗憾的告诉你又出现了认知偏差， 基本上来看从内存的峰值理论带宽计算， 顺序持续写入、读出基本上只能做到峰值带宽的70%，随机读写基本上只能做到50%左右。这些事情似乎通常会被软件团队所忽视，以至于很多设计400Gbps NFV的首席工程师都没有预料到这样的问题。而这样的问题，恰巧被软硬件通吃的一个小团队发现了，于是我们就实现了NetDAM，未来为主机网络做到400Gbps提供了一个参考性的模板。从软件团队来看，NetDAM解决了主内存的I/O使用的问题，并通过memif poll mode driver和CXL隐藏了访存延迟，同时针对大量的多机协同问题（例如MPI_Allreduce)解决了延迟问题。然后由于片上HBM的存在，也可以为大量的加解密算法提供支撑，而不必去CPU做加解密(当然还有一些加密卡例如QAT，但是会放大内存读写带宽)。

另一个问题是，似乎硬件团队特别喜欢P4，特别是最近读到过的各个DPU公司的BP，基本上不谈P4就觉得自己很丢人，大多数都在利用Xilinx SDNet搞快速开发去克隆或者Offload OVS的功能。而从软件视角创业做DPU的团队，基本上清一色的DPDK，或者基于DPDK增强去搞一堆DOCA神马的。。。至于Chisel这样的东西，对软件门槛也高，对硬件门槛也高，通常就被大家束之高阁了….真是有趣…

历史上NetDAM以及以前的Marvell CN10K， 以及思科自己的QFP全系列芯片的经验，对于我而言，就是需要在硬件和软件团队之间找到平衡点，了解各自的难处，才能更好的设计架构。协议编码上的改动必定是破局的关键，例如SRv6这样的技术对于软件团队爽得要死，直接把SID写入Option header 很容易做出一个100Gbps的样机出来，但是对于硬件团队痛苦的要死，线宽不够很多时候parser做不了只能recycle，gSID一类的需要有分支操作，对不起又要xxx…其实很多协议的标准设计失败就来自于设计者对软硬件能力的片面理解， 很多人不解，但是我们不妨等过几年再看看结果就好了：）