Q. I've noticed that in certain examples when using RSS and Dynamic VMQ the first core is skipped in configuration, why?
A. There are numerous networking technologies that help with networking performance. Dynamic VMQ (DVMQ) enables the different VMQs in the NIC to be assigned to different VMs and each VMQ can (not will) be assigned to different logical processors in the system. This helps spread network load over multiple logical processors and also helps the virtual switch distributed traffic very quickly since a specific VMQ is tied to a specific VM. Note that now the host and each VM is tied to a single queue and therefore a single core which means each is limited to the bandwidth supported by a single core, normally around 5-6 Gbps on modern processors. More information on this can be found at http://blogs.technet.com/b/networking/archive/2013/09/10/vmq-deep-dive-1-of-3.aspx.
Receive Side Scaling (RSS) also uses the NIC queues to distribute incoming traffic across multiple logical processors to improve networking performance and because RSS relies on queues this is why you cannot enable RSS and VMQ on the same NIC since the queues can only be used by RSS or VMQ. VMQ is a virtualization technology while RSS is used in native host (no vSwitch cases). It is because of this mutual exclusivity that in a host with multiple NICs it is common to see one NIC used for Live Migration and enable RSS to be used for that traffic and utilizing full bandwidth and another NIC used by the Hyper-V virtual switch to enable DVMQ for the VMs.
There is also a technology called vRSS which enables RSS inside VMs running on Windows Server 2012 R2 Hyper-V (more information at http://blogs.technet.com/b/networking/archive/2013/07/31/drive-up-networking-performance-for-your-most-demanding-workloads-with-virtual-rss.aspx) and spreads workload over the vCPUs of the VM. Note that the vRSS is enabled by Hyper-V and does not use the queues of the NIC therefore vRSS can be used with VMQ.
In both RSS and DVMQ configurations there is a BaseProcessorNumber parameter which often is set to 1 while the actual processors start at 0. This specifies the starting processor to be used for processing by the NIC. The reason for this is to reserve CPU 0 for OS processes since the OS tends to use CPU 0 for most of its system processing and this is a best practice as it removes contention between the system and network processing. Note that if using multiple NICs it is recommended to not overlap logical processor usage if possible, for example the first NIC may use cores 1 through 4 while the next would use cores 5 through 8 and so on. For example:
Set-NetAdapterVmq -Name NIC1 -BaseProcessorGroup -0 -BaseProcessorNumber 1 -MaxProcessorNumber 4 -MaxProcessors 4
Set-NetAdapterVmq -Name NIC2 -BaseProcessorGroup -0 -BaseProcessorNumber 5 -MaxProcessorNumber 8 -MaxProcessors 4
