요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
.. SPDX-License-Identifier: GPL-2.0
3
======================
4
Hyper-V network driver
5
======================
7
Compatibility
8
=============
10
This driver is compatible with Windows Server 2012 R2, 2016 and
11
Windows 10.
13
Features
14
========
16
Checksum 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.
23
Receive 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.
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.
34
On Azure, fragmented UDP packets have high loss rate with L4
35
hashing. Using L3 hashing is recommended in this case.
37
For example, for UDP over IPv4 on eth0:
39
To include UDP port numbers in hashing::
41
ethtool -N eth0 rx-flow-hash udp4 sdfn
43
To exclude UDP port numbers in hashing::
45
ethtool -N eth0 rx-flow-hash udp4 sd
47
To show UDP hash level::
49
ethtool -n eth0 rx-flow-hash udp4
51
Generic 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.
57
Large 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::
64
ethtool -K eth0 lro on
65
ethtool -K eth0 lro off
67
SR-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.
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.
83
Receive 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.
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.
100
XDP 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.
107
hv_netvsc supports XDP in native mode, and transparently sets the XDP
108
program on the associated VF NIC as well.
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.
115
XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO
116
before running XDP::
118
ethtool -K eth0 lro off
120
XDP_REDIRECT action is not yet supported.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
호환성, 체크섬과 RSS
1-51이 문서는 `GPL-2.0` 라이선스를 따릅니다.
Hyper-V 네트워크 드라이버
이 드라이버는 Windows Server 2012 R2, 2016과 Windows 10에 호환됩니다.
체크섬 오프로딩
netvsc는 Hyper-V host가 제공하는 범위에서 체크섬 오프로딩을 지원합니다. Windows Server 2016과 Azure는 IPv4/IPv6의 TCP와 UDP를 모두 지원하지만 Windows Server 2012는 TCP만 지원합니다.
Receive Side Scaling
Hyper-V RSS는 TCP/UDP 패킷을 IP 주소와 포트 번호를 바탕으로 사용 가능한 큐에 분산합니다. ethtool로 IPv4/IPv6와 TCP/UDP별 hash level을 L3 또는 L4로 바꿀 수 있습니다. 기본값은 L4이며 현재 guest 안에서는 TX hash level만 전환할 수 있습니다.
Azure에서 조각난 UDP 패킷은 L4 hashing을 사용할 때 손실률이 높으므로 이 경우 L3 hashing을 권장합니다.
eth0의 IPv4 UDP에서 포트 번호를 hash에 포함하거나 제외하고 현재 수준을 확인합니다.
ethtool -N eth0 rx-flow-hash udp4 sdfn
ethtool -N eth0 rx-flow-hash udp4 sd
ethtool -n eth0 rx-flow-hash udp4.. SPDX-License-Identifier: GPL-2.0
======================
Hyper-V network driver
======================
Compatibility
=============
This driver is compatible with Windows Server 2012 R2, 2016 and
Windows 10.
Features
========
Checksum offload
----------------
The netvsc driver supports checksum offload as long as the
Hyper-V host version does. Windows Server 2016 and Azure
support checksum offload for TCP and UDP for both IPv4 and
IPv6. Windows Server 2012 only supports checksum offload for TCP.
Receive Side Scaling
--------------------
Hyper-V supports receive side scaling. For TCP & UDP, packets can
be distributed among available queues based on IP address and port
number.
For TCP & UDP, we can switch hash level between L3 and L4 by ethtool
command. TCP/UDP over IPv4 and v6 can be set differently. The default
hash level is L4. We currently only allow switching TX hash level
from within the guests.
On Azure, fragmented UDP packets have high loss rate with L4
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
To include UDP port numbers in hashing::
ethtool -N eth0 rx-flow-hash udp4 sdfn
To exclude UDP port numbers in hashing::
ethtool -N eth0 rx-flow-hash udp4 sd
To show UDP hash level::
ethtool -n eth0 rx-flow-hash udp4
Generic Receive Offload, aka GROGRO, LRO/RSC와 SR-IOV
52-83Generic Receive Offload(GRO)
GRO는 기본으로 활성화되며 비슷한 패킷을 합쳐 높은 RX 부하에서 CPU 사용량을 크게 줄입니다.
Large Receive Offload(LRO) / Receive Side Coalescing(RSC)
vSwitch의 LRO/RSC는 가능할 때 여러 TCP segment를 합쳐 패킷별 처리 오버헤드를 줄입니다. Windows Server 2019 이상에서 실행하는 VM에서는 기본으로 켜지며 ethtool로 바꿀 수 있습니다.
ethtool -K eth0 lro on
ethtool -K eth0 lro offSR-IOV 지원
vSwitch와 guest 구성 모두에서 SR-IOV를 켜면 VF가 PCI 장치로 guest에 전달됩니다. guest OS에서는 synthetic netvsc 장치와 VF가 모두 보이며 두 NIC는 같은 MAC 주소를 가집니다.
VF는 netvsc에 종속되고, VF가 사용 가능하며 up 상태가 되면 netvsc가 데이터 경로를 투명하게 VF로 전환합니다. 주소, firewall 등 네트워크 상태는 netvsc에만 적용하고 일반적으로 VF slave를 직접 다루지 마십시오. 특별한 queue discipline이나 flow direction이 필요할 때만 VF에 직접 설정합니다.
--------------------------------
The driver supports GRO and it is enabled by default. GRO coalesces
like packets and significantly reduces CPU usage under heavy Rx
load.
Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
-------------------------------------------------------------
The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet
processing overhead by coalescing multiple TCP segments when possible. The
feature is enabled by default on VMs running on Windows Server 2019 and
later. It may be changed by ethtool command::
ethtool -K eth0 lro on
ethtool -K eth0 lro off
SR-IOV support
--------------
Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV
is enabled in both the vSwitch and the guest configuration, then the
Virtual Function (VF) device is passed to the guest as a PCI
device. In this case, both a synthetic (netvsc) and VF device are
visible in the guest OS and both NIC's have the same MAC address.
The VF is enslaved by netvsc device. The netvsc driver will transparently
switch the data path to the VF when it is available and up.
Network state (addresses, firewall, etc) should be applied only to the
netvsc device; the slave device should not be accessed directly in
most cases. The exceptions are if some special queue discipline or
flow direction is desired, these should be applied directly to the
VF slave device.
Receive Buffer송수신 버퍼와 XDP
84-120Receive buffer
장치를 probe할 때 만든 receive area를 MTU 크기 chunk로 나누며 각 chunk에는 패킷 하나 이상이 들어갈 수 있습니다. ethtool RX ring parameter로 receive section 수를 바꿀 수 있습니다.
send buffer도 패킷을 모아 보내며 보통 6144바이트 chunk로 나눕니다. 작은 패킷은 대개 send buffer로 복사합니다. 버퍼가 일시적으로 고갈되거나 LSO 패킷이면 드라이버가 SKB 데이터 포인터를 host에 제공합니다. 이는 데이터 복사 비용과 VM 메모리를 host가 접근할 수 있게 remap하는 비용 사이의 균형을 맞춥니다.
XDP 지원
XDP는 패킷이 NIC에 도착한 초기 단계에서 eBPF bytecode를 실행해 SKB 할당과 상위 네트워크 계층의 오버헤드를 줄입니다.
`hv_netvsc`는 native XDP를 지원하며 연결된 VF NIC에도 XDP 프로그램을 투명하게 설정합니다. synthetic NIC에서 프로그램을 설정하거나 해제하면 VF에 자동 전파됩니다. VF에 직접 설정하는 방식은 synthetic NIC로 역전파되지 않고 이후 synthetic NIC 설정으로 덮일 수 있으므로 권장하지 않습니다.
XDP는 LRO/RSC와 함께 실행할 수 없으므로 먼저 LRO를 끕니다.
ethtool -K eth0 lro off`XDP_REDIRECT` 동작은 아직 지원하지 않습니다.
--------------
Packets are received into a receive area which is created when device
is probed. The receive area is broken into MTU sized chunks and each may
contain one or more packets. The number of receive sections may be changed
via ethtool Rx ring parameters.
There is a similar send buffer which is used to aggregate packets
for sending. The send area is broken into chunks, typically of 6144
bytes, each of section may contain one or more packets. Small
packets are usually transmitted via copy to the send buffer. However,
if the buffer is temporarily exhausted, or the packet to be transmitted is
an LSO packet, the driver will provide the host with pointers to the data
from the SKB. This attempts to achieve a balance between the overhead of
data copy and the impact of remapping VM memory to be accessible by the
host.
XDP support
-----------
XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early
stage when packets arrive at a NIC card. The goal is to increase performance
for packet processing, reducing the overhead of SKB allocation and other
upper network layers.
hv_netvsc supports XDP in native mode, and transparently sets the XDP
program on the associated VF NIC as well.
Setting / unsetting XDP program on synthetic NIC (netvsc) propagates to
VF NIC automatically. Setting / unsetting XDP program on VF NIC directly
is not recommended, also not propagated to synthetic NIC, and may be
overwritten by setting of synthetic NIC.
XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO
before running XDP::
ethtool -K eth0 lro off
XDP_REDIRECT action is not yet supported.
요약·해설
netvsc.rst:1-120netvsc는 synthetic NIC를 제어 지점으로 유지하면서 사용 가능한 VF로 데이터 경로를 투명하게 넘깁니다. RSS hash 수준, LRO/RSC와 XDP의 상호 배제, synthetic NIC에서 VF로 전파되는 설정 방향이 핵심입니다.
설정을 적용할 위치와 주요 제약입니다.