下午一直在开会，晚上有点时间写几句。

那篇文章我当年就看过。虽然不知道它具体解决什么问题，但大概是想解决网络虚拟化的问题。
这个时间前后大家都在上云，云的核心门槛就是网络虚拟化。
这点除了aws外，早期各家都很扯蛋。各种开源实现，包括各种山寨aws都是耍小聪明绕开了这个核心问题的。
比如有的基于vlan，有的基于ebtables，阿里云早期也出过安全组隔离失效的事情（我记得有这个事情，但搜了下似乎找不到对应的帖子了）。

要解决这个问题，终极思路要爆改交换机设备，把复杂的虚拟化隔离规则在交换机硬件层面实施掉，这样才能offload cpu。
所以才会有这篇文章里面提出的各种问题。这个方向趋势是sdn，其中一个呼声很大的方案是OpenFlow，它允许数据流带上自己的控制逻辑，在交换机上执行了控制逻辑之后再决定后面的流向。但我觉得这个思路不靠谱，太复杂，太难控制，一看就是个典型的又贵又容易出一堆问题的东西。我感觉这个方向可能不一定会形成一个统一天下的下一代网络方案，反正云大厂就那么几个，也只有他们有这个需求，肯定都是diy自己的solution了。

然后，100g带宽对cpu来说主要的问题不是cpu慢，而是延迟高。cpu一个时钟周期可以干很多事情，但取到要处理的数据才是主要瓶颈，毕竟到L3 cache就要十几个周期了，从内存取那就要破百了。此外cpu用来干这个负载，总线上塞满了数据流，基本也干不了别的事情了，这才需要专门的硬件解决方案。fpga是马上就会想到的首选路线，搬运数据好歹是fpga的擅长领域，但fpga的问题是太底层，复杂点的控制逻辑用fpga做本质上还是得做成cpu的样子。我不认为这方面fpga和arm有什么本质区别。两种方案都有妥协的地方。选arm可以很快实现复杂控制逻辑，但提升吞吐量上限可能是个问题；选fpga可以很快怼出个高吞吐量的结果出来show下，但你的控制逻辑是否足够复杂，足够支持你的业务需求，是否要做阉割妥协就是个问题。我觉得没啥本质区别，高性能数据处理的核心问题从来就是data locality，到最后都是技术路线探索清楚定型之后弄个特化npu实现出来。

至于纯软方案，这里有个例子：
https://www.openvswitch.org/support/ovscon2019/day1/1337-OvsCon_2019_2.pdf
它用的硬件是XEON4110 @ 2.1Ghz, 8核×2的配置，虽然插了100GbE卡，但这货居然是跑在PCIE3.0 x8上的，理论带宽只有62Gbps。他用OvS测出的数据是26.5Gbps @ 64byte，不算理想。所以后面他报告的时候被人质疑了，因为DPDK是可以做到100Gbps @ 64byte package的。但大致上，哪怕从这个例子你也可以看出纯软方案并不是你想的那样有多搞不定这个事情。就算是这次的实验，距离100Gbps @ 64byte也就是4倍差距，主频提升下，cpu core提升下，pcie问题解决下就行的。

【 在 leadu 的大作中提到: 】
: 云计算行业的问题主要来自于，在100g带宽的情况下，cpu显得太慢了
: 64小包留给软件工程师的时间，最多也就30左右的时钟周期，对于sdn来说完全不够用
: 所以微软在2014年左右提出了fpga加速，2018年左右在他的全部数据中心完成建设。现在网上随便买它的accelerated network，都是fpga加速的
: ...................
--
FROM 180.111.51.*