The new SMB Multichannel feature improves performance for network interfaces by using multiple TCP connections for a single network interface automatically. SMB will only do this if your network interface reports itself as RSS-capable, which means it can use Receive Side Scaling. You can check that with the Get-SmbServerNetworkInterface or the Get-SmbClientNetworkInterface PowerShell cmdlets. See below:
Without this capability being present on the NIC, using additional TCP connections is not helpful, so SMB will only use a single connection, as it did in previous versions. Virtually all server-class network interfaces should report themselves as RSS-capable these days, but some desktop-class NICs might still say they don’t support RSS. I’ve also seen a few cases where an old driver or a misconfiguration might lead even a 10GbE NIC to report itself as non-RSS-capable.
SMB will always prefer RSS-capable NICs and this can also lead to unexpected behavior. For instance, SMB might prefer a 1GbE NIC over a 10GbE NIC if the 10GbE is reported as non-RSS and the 1GbE NIC reports RSS support. In this case, first confirm that the 10GbE has the latest drivers (you might want to check Windows Update or the manufacturer’s web site). Also, you want to make sure that the NIC configuration wasn’t changed to disable RSS. This can be done using PowerShell cmdlets (Enable-NetAdapterRss and Disable-NetAdapterRss) and is also commonly found under the advanced properties pages for the NIC. See below:
Getting the right type of NIC with the right RSS-capable driver is always your best choice. However, if you really can’t make your preferred NIC show up as RSS-capable, you might need to take some more drastic measures like configuring SMB Multichannel Constraints or disabling RSS on the other NICs.
For more information about SMB Multichannel, see The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0.