原文：http://yiding.9.cn/wp/2057909
上篇探讨也是帮自己梳理下流量卸载的思路。若干同学留言，表示希望进一步。周六要去上海撸个串，今天加个班，以Azure、AWS公开的材料看看卡本身应该关注什么。
1
从Azure看看硬件
Azure的SmartNic如下图，半长半高卡，PCIE Gen3 8x*2 ， 2*50Gb，板载点焊的内存颗粒，Altera FPGA一块，NiC芯片一颗，JTAG口，各种跳线，整体功耗在35w左右的TDP。
SmartNIC上的NiC芯片出正常的网络接口，CPU产生的流量通过NiC进入SmartNIC卡。NiC完成了PCIE接口、RSS负载均衡、负载offload引擎(比如checksum、TSO等)等。流量在FPGA中经过各种流引擎，最终完成NFV功能，以及overlay报文的封装。
controller通过CPU中运行的agent，通过SmartNIC的driver下发各种功能需要的策略。
在SmartNiC中，运行了租户网络的tor交换机（图中为VM Switch）。其中包含了VTEP终结、ACL、计量统计、状态机安全组、SNAT、内网LB等能力。
各项功能会对应到FPGA中hash engine、flow engine等等功能核。根据controller下发的各种配置表格，完成各种NVF，以及overaly的封装解封装。
同时Azure还在这张卡的FPGA上固化了DCQCN的支持，来实现端到端的RDMA flow controll。最终可以将HPC等时延敏感的业务与也走这张卡，避免了通过交换机的pause frame等传统非端到端方案来实现，性能可以和IB一个数量级。感兴趣的同学可以瞅瞅 “sigcomm2016-RDMA over Commodity Ethernet at Scale”。
2
从AWS看看软件
AWS的网络卸载卡已经是第二代了，第一代为10Gb的规格，怀疑和Azure的SmartNIC类似的架构，因为可以100%兼容Intel 82599的驱动。
第二代卡使用了自己的芯片。按照官方的介绍看，AWS为了支持增强网络特性（PCIE passth），不能忍受升级就需要更换驱动的问题，使用了自己的芯片以及可向后兼容的网卡驱动。
ENA这张卡，支持常见的各类卸载，比如ipv4 header checksum offload/TSO IPv4 IPv6 ECN/RSS queue/tcp udp over ipv4 ipv6 checksum offload。
Admin queue来完成卡的管控配置。AENQ queue来异步完成配置命令的状态返回，以及LLDP检测链路状态推送驱动、suspend/resume热迁移信号推送驱动等。TX/RX submition queue各伴随一个complete queue完成报文的首发。额外与驱动配合，实现了驱动推送包头+128 payload的低延时模式，可以降低ms级别的延时。
随着TX/RX submition queue的数量扩展，以及PHY、MAC的不同规格，ENA驱动号称可以支持10/25/40/50/100/400G的ENA卡。
ENA这张卡的目标是，结合ENA网卡驱动，实现高性能，低CPU消耗的overlay网络卸载。同时驱动本身还实现了，RSS hash可配置，流表支持mac、ip、port、协议可配等传统网卡特性，还实现了中断绑定，根据流量自动设置中断频率的等之前需要OS kernel完成的工作。
同时驱动还会往NiC里写驱动、宿主OS等信息，驱动可以根据网卡保持的信息恢复其状态。最终通过suspend/resume方法，实现了SRIOV下的热迁移ready。
其甚至准备支持Intel的DPDK... 这张卡是对传统网卡的一个颠覆，当然只能for自己的运营场景。
3
流量卸载的收益
关于网络流量卸载的收益，前文讲过虚拟机的密度，网络功能节点的通用化，domain0消耗cpu的减少等。其实看看AWS CTO大叔blog的slogan，结合我曾经讲过的盛大云（AWS前员工起家）的在各个host上的分布式镜像缓存的case，再看看各位host domain0的负载，你就可以相信这里空间多大，多少分布式管控程序可以在各个主机的domain0上部署！
说起分布式镜像缓存来，各位做function service的同学，你们的镜像不会都是从镜像的对象存储上拉吧 ：）等你拉下来，别人都跑了几万个op了。