作者简介：吴菁菁， Intel软件工程师，主要从事DPDK PMD的开发工作;陈钊，Intel实习生

文章转载自DPDK与SPDK开源社区

AVF (Adaptive Virtual Function)是一个自适应的virtual function (以下简称VF), 其设计初衷是给虚机提供一个通用VF。这意味着只需要一个VF的驱动，不需要再随着网卡的更新换代来加载不同的驱动。AVF由基本的base features和可协商的advanced features两部分构成，其优点在于已存在的虚机镜像可以在不改变任何代码或者硬件的情况下跑在新的NIC上。英特尔计划从Intel Ethernet 700系列开始支持AVF。

例如，如果现在用的网卡是82599，这时将环境更新为40G或者25G（也就是x710的环境），需要把ixgbe的VF驱动改成i40e的VF 驱动。如果是单机host把ixgbe改成i40e还算合理，但是在愈加云化的今天，如果需要租户VM去改变VF驱动则有悖于云的初衷。基于此，AVF就应运而生了。

从下图得知，在第1代到第N代网卡的更新过程中，不同颜色就代表不同的驱动。从橙色逐渐过度至红色，我们的PF驱动都需要更新。AVF诞生后，在虚机里面的AVF驱动设备对于虚机而言是不变的，所以称之为一个自适应的function。

随着网卡对新功能、更高容量和更高带宽的需求，相应的驱动均需要更新。如何实现呢？最本质的想法是区分base mode和advanced features。Base mode取决于当下网卡最基础的功能，例如它的device ID（所有AVF都共享同一个ID）、当下广泛应用的single level的checksum和TSO offload功能，以及Multi-queue和RSS等。Advanced features则取决于不同代网卡提供的不同功能，需要PF和VF之间具备协商机制。因为PF掌握了所有硬件资源，如果PF知道VF有哪些advanced features，它可以通过协商机制与VF沟通，然后将这些资源曝光给虚机。例如下图，绿色部分表示不改变的部分，红色则代表advanced features可协商的部分。

最后，我们怎样在硬件和软件里实现AVF呢？对于base mode，我们首先需要一个最小的、固定的register definition集合，同时需要一个用于DMA传送的固定metadata（下图中的绿色部分就代表固定不可变的部分）。然后，因为VF要同PF沟通，所以必须在硬件上支持一种mailbox机制。为了实现AVF的自适应, 我们要提供一个软件上的框架来支持 VF与PF的沟通。这称之为虚拟通道（virtual channel），基于硬件的mailbox才能实现（即下图中绿色和红色之间的连接）。

至于advanced features，因为希望在网卡更新后展现一些advanced features ，所以在设计framework时，需要为它的扩展提供空间。首先，提供空间的同时不能影响基本功能。第二，要给past path registers (Queue和Interrupt)提供足够大的范围（range）。因为我们无法估计后续n代的队列数目，所以范围一定要大。第三，虚拟通道的定义必须是通用和可扩展的。因为 VF通过与PF沟通后，才能得知其对应的硬件可以为自己提供哪些advanced features。

当然，AVF也非一成不变。随着一代又一代新网卡的出现，在底层的硬件支持之下，AVF会增加更多功能。

英特尔已经发布了AVF的规范，对于DPDK而言，18.02版本中也已包含了AVF轮询模式驱动。