1.. SPDX-License-Identifier: GPL-2.0 2 3====================== 4Hyper-V network driver 5====================== 6 7Compatibility 8============= 9 10This driver is compatible with Windows Server 2012 R2, 2016 and 11Windows 10. 12 13Features 14======== 15 16Checksum offload 17---------------- 18 The netvsc driver supports checksum offload as long as the 19 Hyper-V host version does. Windows Server 2016 and Azure 20 support checksum offload for TCP and UDP for both IPv4 and 21 IPv6. Windows Server 2012 only supports checksum offload for TCP. 22 23Receive Side Scaling 24-------------------- 25 Hyper-V supports receive side scaling. For TCP & UDP, packets can 26 be distributed among available queues based on IP address and port 27 number. 28 29 For TCP & UDP, we can switch hash level between L3 and L4 by ethtool 30 command. TCP/UDP over IPv4 and v6 can be set differently. The default 31 hash level is L4. We currently only allow switching TX hash level 32 from within the guests. 33 34 On Azure, fragmented UDP packets have high loss rate with L4 35 hashing. Using L3 hashing is recommended in this case. 36 37 For example, for UDP over IPv4 on eth0: 38 39 To include UDP port numbers in hashing:: 40 41 ethtool -N eth0 rx-flow-hash udp4 sdfn 42 43 To exclude UDP port numbers in hashing:: 44 45 ethtool -N eth0 rx-flow-hash udp4 sd 46 47 To show UDP hash level:: 48 49 ethtool -n eth0 rx-flow-hash udp4 50 51Generic Receive Offload, aka GRO 52-------------------------------- 53 The driver supports GRO and it is enabled by default. GRO coalesces 54 like packets and significantly reduces CPU usage under heavy Rx 55 load. 56 57Large Receive Offload (LRO), or Receive Side Coalescing (RSC) 58------------------------------------------------------------- 59 The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet 60 processing overhead by coalescing multiple TCP segments when possible. The 61 feature is enabled by default on VMs running on Windows Server 2019 and 62 later. It may be changed by ethtool command:: 63 64 ethtool -K eth0 lro on 65 ethtool -K eth0 lro off 66 67SR-IOV support 68-------------- 69 Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV 70 is enabled in both the vSwitch and the guest configuration, then the 71 Virtual Function (VF) device is passed to the guest as a PCI 72 device. In this case, both a synthetic (netvsc) and VF device are 73 visible in the guest OS and both NIC's have the same MAC address. 74 75 The VF is enslaved by netvsc device. The netvsc driver will transparently 76 switch the data path to the VF when it is available and up. 77 Network state (addresses, firewall, etc) should be applied only to the 78 netvsc device; the slave device should not be accessed directly in 79 most cases. The exceptions are if some special queue discipline or 80 flow direction is desired, these should be applied directly to the 81 VF slave device. 82 83Receive Buffer 84-------------- 85 Packets are received into a receive area which is created when device 86 is probed. The receive area is broken into MTU sized chunks and each may 87 contain one or more packets. The number of receive sections may be changed 88 via ethtool Rx ring parameters. 89 90 There is a similar send buffer which is used to aggregate packets 91 for sending. The send area is broken into chunks, typically of 6144 92 bytes, each of section may contain one or more packets. Small 93 packets are usually transmitted via copy to the send buffer. However, 94 if the buffer is temporarily exhausted, or the packet to be transmitted is 95 an LSO packet, the driver will provide the host with pointers to the data 96 from the SKB. This attempts to achieve a balance between the overhead of 97 data copy and the impact of remapping VM memory to be accessible by the 98 host. 99 100XDP support 101----------- 102 XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early 103 stage when packets arrive at a NIC card. The goal is to increase performance 104 for packet processing, reducing the overhead of SKB allocation and other 105 upper network layers. 106 107 hv_netvsc supports XDP in native mode, and transparently sets the XDP 108 program on the associated VF NIC as well. 109 110 Setting / unsetting XDP program on synthetic NIC (netvsc) propagates to 111 VF NIC automatically. Setting / unsetting XDP program on VF NIC directly 112 is not recommended, also not propagated to synthetic NIC, and may be 113 overwritten by setting of synthetic NIC. 114 115 XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO 116 before running XDP:: 117 118 ethtool -K eth0 lro off 119 120 XDP_REDIRECT action is not yet supported. 121