流量卸載卡怎麼做

上篇探討也是幫自己梳理下流量卸載的思路。若干同學留言，表示希望進一步。周六要去上海擼個串，今天加個班，以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了。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！