Intel买咖啡,太渴了

It could be a brilliant move, or a huge mistake, and only time will tell.

读了Intel和McAfee的官方blog,对此次收购的双方意图解析如下:

Intel:结合安全厂商,扩大无线设备的战略。这次收购咖啡是组合拳中的第二拳。第一拳来自对Wind River的收购,Wind River是嵌入式软件厂商,在被收购后即推出Secure Embedded Linux,这次收购咖啡应该是对Security的再次补充军力(从Linux内核patch可以看出McAfee在嵌入式安全领域一直有所投资,并收购过secure computing,cyberguard, snapgear 等公司)。

无线设备是Intel的支柱之一,而显然现在多元化的终端设备中移动嵌入式设备是主力,而且移动嵌入式设备也给安全领域带来新的挑战,作为硬件厂商的Intel结合成熟安全厂商的技术,很想在移动设备安全领域有所进展,同时促进Intel的移动设备战略。

McAfee:对于安全领域的循序渐进不再满足,希望通过软硬结合来弥补安全领域中攻方和守方的gap。这是McAfee CTO的解释。但是我的理解是,借用Intel硬件铺平的渠道,平台,市场来大展安全的身手才是她的重要意图。现在看来,合并暂时会更多利于面向consumer的终端安全,但可以预见移动设备会通过商务领域渗透入企业领域,从而影响到企业安全相关产品。

总的来说,个人理解这次收购对于Intel是一小步,对于McAfee是一大步,双方能否同步期望值,达到真正双剑合璧,我持观望态度。从技术上看,软硬结合的安全策略也没有想象中那么容易达到。

Receiving Packet Steering

Linux Kernel 2.6.35最赞的feature就是RPS。

现在的网卡可以接收/发送包的速度已经开始让宿主机的CPU难以跟上。而由于单个CPU的处理能力也慢慢变得难以提升,那么把数据包分布到多个CPU上处理就变得很有必要。在2.6.35内核中,来自Google的Tom Herbert提交了RPS的系列patch,实现了此机制。(对于发出的数据包,已经不存在这样的问题了,因为发送数据包的进程本身就是分散在CPU上运行的。)

Tom的实现非常简单,在netif_rx()和netif_receive_skb()这两条内核收包必经之路上做了以下处理:

  1. 为每个包做一个hash(根据源IP,目标IP,端口)
  2. 根据hash把包放入相应CPU的backlog队列
    • 用户可以通过/sys/class/net/<device>/queues/rx-<n>/rps_cpus设置一个mask,指定特定网卡或者网卡上的某个接收队列(如果支持多接受队列的话)可以包交给特定的几个CPU处理。
    • 包的hash值和rps_cpus的值共同决定了该数据包会放入哪个CPU的backlog队列。

经过以上修改,内核可以支持:

  1. 为网卡或网卡上的接收队列指定数据包可以在哪些CPU上被均衡处理。
  2. 来自网卡的数据包不再被一个CPU的计算瓶颈限制,可以被分布到多个CPU上处理接收。
  3. 由于hash值是根据源IP,目标IP和端口计算得出,因此同一个transaction的包被同一个CPU处理,可以达到很好cache命中率,从而提高性能。

Google的生产线上已经使用了RPS,效果不错。这里是Tom给的一些测试数据,明显看到CPU利用率提升以及网络PPS和TPS的提升。

e1000e on 8 core Intel
Without RPS: 108K tps at 33% CPU
With RPS:    311K tps at 64% CPU

forcedeth on 16 core AMD
Without RPS: 156K tps at 15% CPU
With RPS:    404K tps at 49% CPU

bnx2x on 16 core AMD
Without RPS  567K tps at 61% CPU (4 HW RX queues)
Without RPS  738K tps at 96% CPU (8 HW RX queues)
With RPS:    854K tps at 76% CPU (4 HW RX queues)

但是同时,这里有一些limitation。

  1. 一个数据包到达后,中断所到达的CPU负责分配,这时会通过SKB内容计算hash,由于是第一次读这个SKB,所以发生cache miss正常。但是之后这个数据包可能会被分配到其他CPU上处理,对于另一个CPU来说,SKB仍然是一个未知内容,所以cache miss又会发生,这次的cache miss就是RPS带来的新开销。不过幸好,很多网卡都天生支持计算这样的hash,驱动只需要把该值存入SKB,就可以提高cache hit,以及计算机整体性能。
  2. rps_cpus可以在运行时被动态改变,但是这样的改动可能会导致包的乱序。因为改动前某个transaction的数据包都是由某个CPU处理,而rps_cpus改变,可能导致该transaction的包被发往另一个CPU上处理,如果后到的包在第二个CPU上被处理的速度快于先到的包在第一个CPU上被处理的速度,就会发生乱序。所以尽可能不要频繁改变rps_cpus的值。