在之前的博文中（）聊过虚拟化中的SRIOV技术，即单根虚拟化，在启用了SRIOV之后，虚拟机通过硬件实现VF（Virtual Function）能力，使得性能近乎于物理机效果。
当然，虚拟化技术以及云计算平台已经发展的越来越快，相关的硬件加速技术也是有很多种选择，并且在不同的场合需要用户选取适合自己的解决方案，而不是盲目跟风，究竟哪些功能有用，哪些功能之间又互相冲突，都需要仔细的去评估，今天就想聊一聊有关虚拟化环境中的另外两个硬件辅助功能，RSS（接收端扩展）与VMQ（虚拟机队列）。
######################################################################
首先在开始之前先说明一下我的演示环境：
操作系统：Windows Server 2012 R2
物理机：HP DL160 G6
网卡：Intel千兆（支持RSS及VMQ）
这里十分遗憾的是我的网卡是1Gi速率的而不是10Gi的，没办法屌丝只能这样了，因此无法完全说明开启VMQ之后的效果（具体缘由在文章后面会提到）
######################################################################
好的，现在开始进入正题，为什么要把RSS和VMQ拿到一起来说呢，因为这两个功能的初衷是比较类似的，先说RSS，它通常是在纯物理环境下启用的，RSS所实现的效果非常简单明了，如下图：
在物理NIC不支持RSS功能的时候，网络流量的负载是通过一颗逻辑CPU来处理的，是的你没有看错，即便你的CPU能力很屌，多路N线程也只会调用一颗LP（logical processor）来干活儿，那么就会出现一个瓶颈问题，而RSS正是通过调用全部LP来处理网络负载来解决了这一性能问题。好就好在什么呢？如果是1Gi速率的话，目前这个年代单颗LP处理起来还是富富有余的，但众所周知，以太网发展十分迅速，10Gi速率的出现彻底打破了这一局面，当下OS（以Windows为例）调用单颗LP只能run到3.5~4.5Gi的能力，是的没错，也就意味着在万兆环境下，若没有RSS或VMQ的辅助，那么必将损失掉很多性能。
#####################################################################
在我的DL160上，首先来看一下当前网卡的工作模式，RSS属性默认都是开启的（这已经是服务器级别最基本的一个功能了），为了对比效果我先禁用它，如下图：
之后要确认一下我的环境尚未开启hypervisor，也就是以Windows平台为例，我没有开启Hyper-V功能（虚拟化层），为什么要确认这一步呢，因为RSS在虚拟化环境中将不起作用，尽管它可能处于启用状态，但始终是无效的，为什么一会儿再说。
接下来我通过网络共享做一个拷贝的动作，眼尖的童鞋可能会发现我的速率是百兆的。。。是的你没看错。。。:(
此时在DL160这台服务器上，大部分负载都是通过LP0来run的，通过性能计数器可以看的更明显，如下图：
我重新启用RSS功能做一个对比
仍然是刚才的拷贝，此时服务器已经在调用所有CPU来处理了，我的这个截图可能看上去不是特别的明显，因为理论上来讲，RSS功能在千兆网卡上可能也不会起作用，正如上面所讲的，单颗LP足以应付1Gi速率的负载。
####################################################################
那么在了解了RSS功能之后，再来看看VMQ，虚拟机队列顾名思义是适用于虚拟化环境下的，那为什么不能直接用RSS呢？看下图：
以Windows平台为例，在启用了hypervisor之后，整个基础架构发生了很大变化，首先是产生父子区域，即主机OS与Guest OS，其次就是最要命的——“虚拟交换机”，virtual switch通过路由、过滤、扩展、访问控制列表、转发、VM Bus等堆栈组合而成，首先从系统层面的视角来看，主机host与VM之间的流量是平起平坐的，那么此时从外面进来的流量通过物理NIC之后需要分发到不同的目的地，例如主机OS或者转发到某一台VM上，也就是说不存在针对物理机来调用所有LP了，那么RSS功能就失效了，你就算开着它也没用。
因此回到本篇的议题，为什么要把RSS与VMQ拿到一起说，因为VMQ正是为了解决在虚拟化环境中出现的性能瓶颈问题而诞生的，如上图所示，首先物理NIC需要硬件支持VMQ功能，然后不同厂商的不同型号，一个NIC口可以支持若干个队列，每一个队列将会关联到一颗LP上，然后这条路径将会对应到唯一的目的地，即主机OS或者某一台VM。
这样一来首先入方向流量的转发和路由功能将会在NIC上完成，不需要在虚拟交换机上做过多的停留，此外每条路径在万兆（10Gi）条件下可以发挥最高将近5Gi的能力，而不是所有资源共享一条5Gi左右链路（若不启用VMQ功能整个主机只由一颗LP负载所有VM和父OS流量）。
#####################################################################
那么可能有的童鞋会想说，虽然我有了VMQ可以解决一部分性能问题了，但是我的VM可能有很多颗VP（virtual processor），如何发挥最大性能呢？很可喜的是，在Windows Server 2012 R2中，Hyper-V已经支持一项叫做vRSS的功能了，顾名思义，现在在虚机中我们也可以实现RSS的效果了。
想要实现vRSS的前提是，物理NIC要支持VMQ功能，并且在Hyper-V的设置用，确保虚拟机的vNIC启用了“虚拟机队列”功能。如下图：
接下来看一下对比，实际想过和物理机测试RSS的差不多的，在Guest OS中查看虚拟机的vNIC属性，当前vNIC的RSS功能默认是关闭的。如下图：
接下来查看一下宿主机上物理NIC的VMQ属性，以我的环境为例，我把“以太网”和“以太网2”做了Teaming，因此只需要关注两块NIC是否启用了VMQ即可。如下图：
在这里要说明一下，通过PowerShell返回的结果来看，我的网卡VMQ属性有几列字段需要重点关注一下：
接下来在没有启用虚拟机RSS功能（也就是vRSS）的前提下进行一个拷贝动作，，可以再Guest OS看到当前只调用了VP0。如下图：
通过物理机的性能计数器来观测VP使用情况会更明显，如下图：
接下来启用虚拟机的RSS功能，即vRSS，如下图：
继续进行一个拷贝工作，观察Guest OS内CPU使用情况，如下图：
同样在物理机上通过性能计数器观察VP使用率，如下图：
若在万兆条件下测试效果会更直观
######################################################################
上面主要看了一下RSS与vRSS的一些演示，特别是vRSS也是要基于VMQ功能才可以启用的，那么下面就看一看VMQ的效果。
在此之前还是想多说一说有关VMQ的概念性问题，因为在我看来，实际体验一项功能之前，十分有必要去了解它的运行机制和工作原理以及关键的要点。
在Windows Server 2012中，VMQ变得更加智能化，微软称之为动态VMQ，也就是如下图所示：
原来LP1与LP2是分别处理VM1与VM2负载的。
当网络负载变小的时候，VMQ会合并队列，将VM1与VM2的负载整合到LP1上去run。
####################################################################
上面提到的是动态VMQ，而当用户想将VMQ与SRIOV复用时，就需要注意了——鱼与熊掌不可兼得，为什么呢？看下图：
从起点，到尽头，也许快乐，或有时孤独，
