← Documents Documentation/networking/device_drivers/ethernet/intel/ice.rst GitHub 원문 ↗

Linux 6.18.37 · Networking

Linux Base Driver for the Intel(R) Ethernet Controller 800 Series

Intel ice의 DDP, Flow Director·aRFS, SR-IOV 보안, DCB·QinQ·offload, firmware logging과 interrupt tuning을 설명합니다.

Source pathDocumentation/networking/device_drivers/ethernet/intel/ice.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

ice.rst:1-1219

ice는 Intel 800 Series PF의 packet pipeline과 queue, SR-IOV security, time synchronization 및 firmware 진단을 폭넓게 제어합니다. DDP package와 Flow Director input set처럼 device 또는 flow type 전체에서 공유되는 상태가 많으므로 update 순서, 상호 배타 기능과 reset 범위를 먼저 확인해야 합니다.

Driver scope
항목내용
PF driverice
VF driveriavf
Fast pathXDP, AF_XDP zero-copy
XDP frame 제한3KB 이하
진단ethtool, lspci

기본 연계 driver와 data-path 제약입니다.

Receive stress 완화
Packet drop 확인memory channel을 vendor 권장 구성BIOS/UEFI Performance profiletuned workload profile

PCIe·DMA latency로 인한 drop을 줄이는 순서입니다.

Reset 영향 범위
Reset영향
PF해당 PF component만
COREadapter 전체와 모든 PF
GLOBALCORE + MAC + PHY
Representor VFswitchdev의 해당 VF

ethtool reset 종류별 재초기화 범위입니다.

DDP package lifecycle
device initializeserial-specific package 확인없으면 ice.pkgvalid package loadadvanced pipeline
package missing/invalid해당 PF Safe Modebasic traffic·NVM update만
package 교체모든 PF unloaddriver reload

default와 device-specific package 선택 및 Safe Mode 진입입니다.

Flow Director 규칙
항목규칙
Flow typeIPv4/6, TCP, UDP, SCTP
Actionqueue 지정, -1은 drop
Maskinverted, partial field mask 미지원
Input set같은 type의 모든 filter에서 동일
ntuple offdriver와 hardware filter flush
Flexible offset최대 64, 짝수

filter를 안전하게 program하기 위한 공통 제약입니다.

RSS와 aRFS
RSS hash field 선택ntuple onglobal RPS tablequeue별 rps_flow_cntIRQ affinityapplication CPU

application CPU affinity까지 이어지는 receive steering입니다.

SR-IOV resource와 배타성
항목조건
VF 상한모든 port 합계 256
PF별 상한sriov_totalvfs로 확인
LAG/bondingSR-IOV와 상호 배타
Port VLANVF/VM 시작 전에 구성
Host-assigned MACVM 내부 변경 차단

VF 생성과 host policy의 핵심 상한입니다.

Trusted VF security
VF trust onlimited/true promisc 유형 선택VM에서 promisc 요청VLAN traffic 수신
spoofed 또는 invalid trafficMDD eventdrop/queue disable수동 또는 자동 VF reset

trust, promiscuous와 MDD 대응 관계입니다.

Jumbo와 link 설정
항목값·조건
Jumbo 활성화MTU > 1500
최대 MTU / frame9702 / 9728 bytes
Packet lossflow control로 완화 가능
1Gbps 이상강제 고정 불가, advertising 사용
Switch partnerspeed/duplex 설정 일치

frame 크기 및 negotiation 주의사항입니다.

DCBX mode
ModeLLDP 처리Local DCB
FirmwareFW가 intercept·negotiate조회만
Softwarenetwork stack·user agent조회와 설정
공통TC0 필요상호 배타

firmware와 software LLDP agent 차이입니다.

QinQ 제약
항목조건
Receiverxvlan off 필요
OffloadRx checksum·VLAN acceleration 미지원
Port 공존0x8100 VLAN과 혼용 불가
VF Txport VLAN 없음 + spoofchk off
True promiscinner VLAN traffic 일부 누락 가능

0x88A8/0x8100 double VLAN 운용 조건입니다.

Offload와 timing I/O
기능핵심 조건
VXLAN/GENEVEstateless offload default on
UDP segmentationpayload 최대 64K, application 지원
PTP SDPperiodic output + external timestamp
DPLL pininput/output path 수동 구성
GNSSCONFIG_GNSS, /dev/gnss<id>

overlay, segmentation, PTP·GNSS 기능입니다.

FW logging controls
File역할범위·조건
modules/*module log levelnone-error-warning-normal-verbose
enableevent 전송 on/off1 / 0
databinary log 읽기·삭제삭제는 logging off
nr_messagesARQ push 빈도1-128, 권장 10
log_sizedriver buffer128K-2M, default 1M

PF0 debugfs logging의 주요 knob입니다.

Performance tuning
목표설정효과
Rx drop 완화ethtool -G rx Ntemporary buffering 증가
낮은 CPUrx/tx-usecs 80queue당 약 12,500/s
낮은 latencyrx/tx-usecs 0ITR off
Queue별queue_mask + rx-usecs선택 queue만 조정
Global boundrx-usecs-high 0-2364,237-250,000/s

ring과 interrupt 설정의 대표 trade-off입니다.

VM locality 최적화
device local_cpulist 확인vcpupin으로 개별 lCPU 고정VM Rx/Tx queue 최대화

vCPU, NUMA locality와 queue 수를 맞춥니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: GPL-2.0+
2
3 =================================================================
4 Linux Base Driver for the Intel(R) Ethernet Controller 800 Series
5 =================================================================
6
7 Intel ice Linux driver.
8 Copyright(c) 2018-2021 Intel Corporation.
9
10 Contents
11 ========
12
13 - Overview
14 - Identifying Your Adapter
15 - Important Notes
16 - Additional Features & Configurations
17 - Performance Optimization
18
19
20 The associated Virtual Function (VF) driver for this driver is iavf.
21
22 Driver information can be obtained using ethtool and lspci.
23
24 For questions related to hardware requirements, refer to the documentation
25 supplied with your Intel adapter. All hardware requirements listed apply to use
26 with Linux.
27
28 This driver supports XDP (Express Data Path) and AF_XDP zero-copy. Note that
29 XDP is blocked for frame sizes larger than 3KB.
30
31
32 Identifying Your Adapter
33 ========================
34 For information on how to identify your adapter, and for the latest Intel
35 network drivers, refer to the Intel Support website:
36 https://www.intel.com/support
37
38
39 Important Notes
40 ===============
41
42 Packet drops may occur under receive stress
43 -------------------------------------------
44 Devices based on the Intel(R) Ethernet Controller 800 Series are designed to
45 tolerate a limited amount of system latency during PCIe and DMA transactions.
46 If these transactions take longer than the tolerated latency, it can impact the
47 length of time the packets are buffered in the device and associated memory,
48 which may result in dropped packets. These packets drops typically do not have
49 a noticeable impact on throughput and performance under standard workloads.
50
51 If these packet drops appear to affect your workload, the following may improve
52 the situation:
53
54 1) Make sure that your system's physical memory is in a high-performance
55 configuration, as recommended by the platform vendor. A common
56 recommendation is for all channels to be populated with a single DIMM
57 module.
58 2) In your system's BIOS/UEFI settings, select the "Performance" profile.
59 3) Your distribution may provide tools like "tuned," which can help tweak
60 kernel settings to achieve better standard settings for different workloads.
61
62
63 Configuring SR-IOV for improved network security
64 ------------------------------------------------
65 In a virtualized environment, on Intel(R) Ethernet Network Adapters that
66 support SR-IOV, the virtual function (VF) may be subject to malicious behavior.
67 Software-generated layer two frames, like IEEE 802.3x (link flow control), IEEE
68 802.1Qbb (priority based flow-control), and others of this type, are not
69 expected and can throttle traffic between the host and the virtual switch,
70 reducing performance. To resolve this issue, and to ensure isolation from
71 unintended traffic streams, configure all SR-IOV enabled ports for VLAN tagging
72 from the administrative interface on the PF. This configuration allows
73 unexpected, and potentially malicious, frames to be dropped.
74
75 See "Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports" later in this
76 README for configuration instructions.
77
78
79 Do not unload port driver if VF with active VM is bound to it
80 -------------------------------------------------------------
81 Do not unload a port's driver if a Virtual Function (VF) with an active Virtual
82 Machine (VM) is bound to it. Doing so will cause the port to appear to hang.
83 Once the VM shuts down, or otherwise releases the VF, the command will
84 complete.
85
86
87 Additional Features and Configurations
88 ======================================
89
90 ethtool
91 -------
92 The driver utilizes the ethtool interface for driver configuration and
93 diagnostics, as well as displaying statistical information. The latest ethtool
94 version is required for this functionality. Download it at:
95 https://kernel.org/pub/software/network/ethtool/
96
97 NOTE: The rx_bytes value of ethtool does not match the rx_bytes value of
98 Netdev, due to the 4-byte CRC being stripped by the device. The difference
99 between the two rx_bytes values will be 4 x the number of Rx packets. For
100 example, if Rx packets are 10 and Netdev (software statistics) displays
101 rx_bytes as "X", then ethtool (hardware statistics) will display rx_bytes as
102 "X+40" (4 bytes CRC x 10 packets).
103
104 ethtool reset
105 -------------
106 The driver supports 3 types of resets:
107
108 - PF reset - resets only components associated with the given PF, does not
109 impact other PFs
110
111 - CORE reset - whole adapter is affected, reset all PFs
112
113 - GLOBAL reset - same as CORE but mac and phy components are also reinitialized
114
115 These are mapped to ethtool reset flags as follow:
116
117 - PF reset:
118
119 # ethtool --reset <ethX> irq dma filter offload
120
121 - CORE reset:
122
123 # ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared \
124 ram-shared
125
126 - GLOBAL reset:
127
128 # ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared \
129 mac-shared phy-shared ram-shared
130
131 In switchdev mode you can reset a VF using port representor:
132
133 # ethtool --reset <repr> irq dma filter offload
134
135
136 Viewing Link Messages
137 ---------------------
138 Link messages will not be displayed to the console if the distribution is
139 restricting system messages. In order to see network driver link messages on
140 your console, set dmesg to eight by entering the following::
141
142 # dmesg -n 8
143
144 NOTE: This setting is not saved across reboots.
145
146
147 Dynamic Device Personalization
148 ------------------------------
149 Dynamic Device Personalization (DDP) allows you to change the packet processing
150 pipeline of a device by applying a profile package to the device at runtime.
151 Profiles can be used to, for example, add support for new protocols, change
152 existing protocols, or change default settings. DDP profiles can also be rolled
153 back without rebooting the system.
154
155 The DDP package loads during device initialization. The driver looks for
156 ``intel/ice/ddp/ice.pkg`` in your firmware root (typically ``/lib/firmware/``
157 or ``/lib/firmware/updates/``) and checks that it contains a valid DDP package
158 file.
159
160 NOTE: Your distribution should likely have provided the latest DDP file, but if
161 ice.pkg is missing, you can find it in the linux-firmware repository or from
162 intel.com.
163
164 If the driver is unable to load the DDP package, the device will enter Safe
165 Mode. Safe Mode disables advanced and performance features and supports only
166 basic traffic and minimal functionality, such as updating the NVM or
167 downloading a new driver or DDP package. Safe Mode only applies to the affected
168 physical function and does not impact any other PFs. See the "Intel(R) Ethernet
169 Adapters and Devices User Guide" for more details on DDP and Safe Mode.
170
171 NOTES:
172
173 - If you encounter issues with the DDP package file, you may need to download
174 an updated driver or DDP package file. See the log messages for more
175 information.
176
177 - The ice.pkg file is a symbolic link to the default DDP package file.
178
179 - You cannot update the DDP package if any PF drivers are already loaded. To
180 overwrite a package, unload all PFs and then reload the driver with the new
181 package.
182
183 - Only the first loaded PF per device can download a package for that device.
184
185 You can install specific DDP package files for different physical devices in
186 the same system. To install a specific DDP package file:
187
188 1. Download the DDP package file you want for your device.
189
190 2. Rename the file ice-xxxxxxxxxxxxxxxx.pkg, where 'xxxxxxxxxxxxxxxx' is the
191 unique 64-bit PCI Express device serial number (in hex) of the device you
192 want the package downloaded on. The filename must include the complete
193 serial number (including leading zeros) and be all lowercase. For example,
194 if the 64-bit serial number is b887a3ffffca0568, then the file name would be
195 ice-b887a3ffffca0568.pkg.
196
197 To find the serial number from the PCI bus address, you can use the
198 following command::
199
200 # lspci -vv -s af:00.0 | grep -i Serial
201 Capabilities: [150 v1] Device Serial Number b8-87-a3-ff-ff-ca-05-68
202
203 You can use the following command to format the serial number without the
204 dashes::
205
206 # lspci -vv -s af:00.0 | grep -i Serial | awk '{print $7}' | sed s/-//g
207 b887a3ffffca0568
208
209 3. Copy the renamed DDP package file to
210 ``/lib/firmware/updates/intel/ice/ddp/``. If the directory does not yet
211 exist, create it before copying the file.
212
213 4. Unload all of the PFs on the device.
214
215 5. Reload the driver with the new package.
216
217 NOTE: The presence of a device-specific DDP package file overrides the loading
218 of the default DDP package file (ice.pkg).
219
220
221 Intel(R) Ethernet Flow Director
222 -------------------------------
223 The Intel Ethernet Flow Director performs the following tasks:
224
225 - Directs receive packets according to their flows to different queues
226 - Enables tight control on routing a flow in the platform
227 - Matches flows and CPU cores for flow affinity
228
229 NOTE: This driver supports the following flow types:
230
231 - IPv4
232 - TCPv4
233 - UDPv4
234 - SCTPv4
235 - IPv6
236 - TCPv6
237 - UDPv6
238 - SCTPv6
239
240 Each flow type supports valid combinations of IP addresses (source or
241 destination) and UDP/TCP/SCTP ports (source and destination). You can supply
242 only a source IP address, a source IP address and a destination port, or any
243 combination of one or more of these four parameters.
244
245 NOTE: This driver allows you to filter traffic based on a user-defined flexible
246 two-byte pattern and offset by using the ethtool user-def and mask fields. Only
247 L3 and L4 flow types are supported for user-defined flexible filters. For a
248 given flow type, you must clear all Intel Ethernet Flow Director filters before
249 changing the input set (for that flow type).
250
251
252 Flow Director Filters
253 ---------------------
254 Flow Director filters are used to direct traffic that matches specified
255 characteristics. They are enabled through ethtool's ntuple interface. To enable
256 or disable the Intel Ethernet Flow Director and these filters::
257
258 # ethtool -K <ethX> ntuple <off|on>
259
260 NOTE: When you disable ntuple filters, all the user programmed filters are
261 flushed from the driver cache and hardware. All needed filters must be re-added
262 when ntuple is re-enabled.
263
264 To display all of the active filters::
265
266 # ethtool -u <ethX>
267
268 To add a new filter::
269
270 # ethtool -U <ethX> flow-type <type> src-ip <ip> [m <ip_mask>] dst-ip <ip>
271 [m <ip_mask>] src-port <port> [m <port_mask>] dst-port <port> [m <port_mask>]
272 action <queue>
273
274 Where:
275 <ethX> - the Ethernet device to program
276 <type> - can be ip4, tcp4, udp4, sctp4, ip6, tcp6, udp6, sctp6
277 <ip> - the IP address to match on
278 <ip_mask> - the IPv4 address to mask on
279 NOTE: These filters use inverted masks.
280 <port> - the port number to match on
281 <port_mask> - the 16-bit integer for masking
282 NOTE: These filters use inverted masks.
283 <queue> - the queue to direct traffic toward (-1 discards the
284 matched traffic)
285
286 To delete a filter::
287
288 # ethtool -U <ethX> delete <N>
289
290 Where <N> is the filter ID displayed when printing all the active filters,
291 and may also have been specified using "loc <N>" when adding the filter.
292
293 EXAMPLES:
294
295 To add a filter that directs packet to queue 2::
296
297 # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
298 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]
299
300 To set a filter using only the source and destination IP address::
301
302 # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
303 192.168.10.2 action 2 [loc 1]
304
305 To set a filter based on a user-defined pattern and offset::
306
307 # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
308 192.168.10.2 user-def 0x4FFFF action 2 [loc 1]
309
310 where the value of the user-def field contains the offset (4 bytes) and
311 the pattern (0xffff).
312
313 To match TCP traffic sent from 192.168.0.1, port 5300, directed to 192.168.0.5,
314 port 80, and then send it to queue 7::
315
316 # ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5
317 src-port 5300 dst-port 80 action 7
318
319 To add a TCPv4 filter with a partial mask for a source IP subnet::
320
321 # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.0.0 m 0.255.255.255 dst-ip
322 192.168.5.12 src-port 12600 dst-port 31 action 12
323
324 NOTES:
325
326 For each flow-type, the programmed filters must all have the same matching
327 input set. For example, issuing the following two commands is acceptable::
328
329 # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
330 # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10
331
332 Issuing the next two commands, however, is not acceptable, since the first
333 specifies src-ip and the second specifies dst-ip::
334
335 # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
336 # ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10
337
338 The second command will fail with an error. You may program multiple filters
339 with the same fields, using different values, but, on one device, you may not
340 program two tcp4 filters with different matching fields.
341
342 The ice driver does not support matching on a subportion of a field, thus
343 partial mask fields are not supported.
344
345
346 Flex Byte Flow Director Filters
347 -------------------------------
348 The driver also supports matching user-defined data within the packet payload.
349 This flexible data is specified using the "user-def" field of the ethtool
350 command in the following way:
351
352 .. table::
353
354 ============================== ============================
355 ``31 28 24 20 16`` ``15 12 8 4 0``
356 ``offset into packet payload`` ``2 bytes of flexible data``
357 ============================== ============================
358
359 For example,
360
361 ::
362
363 ... user-def 0x4FFFF ...
364
365 tells the filter to look 4 bytes into the payload and match that value against
366 0xFFFF. The offset is based on the beginning of the payload, and not the
367 beginning of the packet. Thus
368
369 ::
370
371 flow-type tcp4 ... user-def 0x8BEAF ...
372
373 would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the
374 TCP/IPv4 payload.
375
376 Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload.
377 Thus to match the first byte of the payload, you must actually add 4 bytes to
378 the offset. Also note that ip4 filters match both ICMP frames as well as raw
379 (unknown) ip4 frames, where the payload will be the L3 payload of the IP4
380 frame.
381
382 The maximum offset is 64. The hardware will only read up to 64 bytes of data
383 from the payload. The offset must be even because the flexible data is 2 bytes
384 long and must be aligned to byte 0 of the packet payload.
385
386 The user-defined flexible offset is also considered part of the input set and
387 cannot be programmed separately for multiple filters of the same type. However,
388 the flexible data is not part of the input set and multiple filters may use the
389 same offset but match against different data.
390
391
392 RSS Hash Flow
393 -------------
394 Allows you to set the hash bytes per flow type and any combination of one or
395 more options for Receive Side Scaling (RSS) hash byte configuration.
396
397 ::
398
399 # ethtool -N <ethX> rx-flow-hash <type> <option>
400
401 Where <type> is:
402 tcp4 signifying TCP over IPv4
403 udp4 signifying UDP over IPv4
404 gtpc4 signifying GTP-C over IPv4
405 gtpc4t signifying GTP-C (include TEID) over IPv4
406 gtpu4 signifying GTP-U over IPV4
407 gtpu4e signifying GTP-U and Extension Header over IPV4
408 gtpu4u signifying GTP-U PSC Uplink over IPV4
409 gtpu4d signifying GTP-U PSC Downlink over IPV4
410 tcp6 signifying TCP over IPv6
411 udp6 signifying UDP over IPv6
412 gtpc6 signifying GTP-C over IPv6
413 gtpc6t signifying GTP-C (include TEID) over IPv6
414 gtpu6 signifying GTP-U over IPV6
415 gtpu6e signifying GTP-U and Extension Header over IPV6
416 gtpu6u signifying GTP-U PSC Uplink over IPV6
417 gtpu6d signifying GTP-U PSC Downlink over IPV6
418 And <option> is one or more of:
419 s Hash on the IP source address of the Rx packet.
420 d Hash on the IP destination address of the Rx packet.
421 f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
422 n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.
423 e Hash on GTP Packet on TEID (4bytes) of the Rx packet.
424
425
426 Accelerated Receive Flow Steering (aRFS)
427 ----------------------------------------
428 Devices based on the Intel(R) Ethernet Controller 800 Series support
429 Accelerated Receive Flow Steering (aRFS) on the PF. aRFS is a load-balancing
430 mechanism that allows you to direct packets to the same CPU where an
431 application is running or consuming the packets in that flow.
432
433 NOTES:
434
435 - aRFS requires that ntuple filtering is enabled via ethtool.
436 - aRFS support is limited to the following packet types:
437
438 - TCP over IPv4 and IPv6
439 - UDP over IPv4 and IPv6
440 - Nonfragmented packets
441
442 - aRFS only supports Flow Director filters, which consist of the
443 source/destination IP addresses and source/destination ports.
444 - aRFS and ethtool's ntuple interface both use the device's Flow Director. aRFS
445 and ntuple features can coexist, but you may encounter unexpected results if
446 there's a conflict between aRFS and ntuple requests. See "Intel(R) Ethernet
447 Flow Director" for additional information.
448
449 To set up aRFS:
450
451 1. Enable the Intel Ethernet Flow Director and ntuple filters using ethtool.
452
453 ::
454
455 # ethtool -K <ethX> ntuple on
456
457 2. Set up the number of entries in the global flow table. For example:
458
459 ::
460
461 # NUM_RPS_ENTRIES=16384
462 # echo $NUM_RPS_ENTRIES > /proc/sys/net/core/rps_sock_flow_entries
463
464 3. Set up the number of entries in the per-queue flow table. For example:
465
466 ::
467
468 # NUM_RX_QUEUES=64
469 # for file in /sys/class/net/$IFACE/queues/rx-*/rps_flow_cnt; do
470 # echo $(($NUM_RPS_ENTRIES/$NUM_RX_QUEUES)) > $file;
471 # done
472
473 4. Disable the IRQ balance daemon (this is only a temporary stop of the service
474 until the next reboot).
475
476 ::
477
478 # systemctl stop irqbalance
479
480 5. Configure the interrupt affinity.
481
482 See ``/Documentation/core-api/irq/irq-affinity.rst``
483
484
485 To disable aRFS using ethtool::
486
487 # ethtool -K <ethX> ntuple off
488
489 NOTE: This command will disable ntuple filters and clear any aRFS filters in
490 software and hardware.
491
492 Example Use Case:
493
494 1. Set the server application on the desired CPU (e.g., CPU 4).
495
496 ::
497
498 # taskset -c 4 netserver
499
500 2. Use netperf to route traffic from the client to CPU 4 on the server with
501 aRFS configured. This example uses TCP over IPv4.
502
503 ::
504
505 # netperf -H <Host IPv4 Address> -t TCP_STREAM
506
507
508 Enabling Virtual Functions (VFs)
509 --------------------------------
510 Use sysfs to enable virtual functions (VF).
511
512 For example, you can create 4 VFs as follows::
513
514 # echo 4 > /sys/class/net/<ethX>/device/sriov_numvfs
515
516 To disable VFs, write 0 to the same file::
517
518 # echo 0 > /sys/class/net/<ethX>/device/sriov_numvfs
519
520 The maximum number of VFs for the ice driver is 256 total (all ports). To check
521 how many VFs each PF supports, use the following command::
522
523 # cat /sys/class/net/<ethX>/device/sriov_totalvfs
524
525 Note: You cannot use SR-IOV when link aggregation (LAG)/bonding is active, and
526 vice versa. To enforce this, the driver checks for this mutual exclusion.
527
528
529 Displaying VF Statistics on the PF
530 ----------------------------------
531 Use the following command to display the statistics for the PF and its VFs::
532
533 # ip -s link show dev <ethX>
534
535 NOTE: The output of this command can be very large due to the maximum number of
536 possible VFs.
537
538 The PF driver will display a subset of the statistics for the PF and for all
539 VFs that are configured. The PF will always print a statistics block for each
540 of the possible VFs, and it will show zero for all unconfigured VFs.
541
542
543 Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports
544 --------------------------------------------------------
545 To configure VLAN tagging for the ports on an SR-IOV enabled adapter, use the
546 following command. The VLAN configuration should be done before the VF driver
547 is loaded or the VM is booted. The VF is not aware of the VLAN tag being
548 inserted on transmit and removed on received frames (sometimes called "port
549 VLAN" mode).
550
551 ::
552
553 # ip link set dev <ethX> vf <id> vlan <vlan id>
554
555 For example, the following will configure PF eth0 and the first VF on VLAN 10::
556
557 # ip link set dev eth0 vf 0 vlan 10
558
559
560 Enabling a VF link if the port is disconnected
561 ----------------------------------------------
562 If the physical function (PF) link is down, you can force link up (from the
563 host PF) on any virtual functions (VF) bound to the PF.
564
565 For example, to force link up on VF 0 bound to PF eth0::
566
567 # ip link set eth0 vf 0 state enable
568
569 Note: If the command does not work, it may not be supported by your system.
570
571
572 Setting the MAC Address for a VF
573 --------------------------------
574 To change the MAC address for the specified VF::
575
576 # ip link set <ethX> vf 0 mac <address>
577
578 For example::
579
580 # ip link set <ethX> vf 0 mac 00:01:02:03:04:05
581
582 This setting lasts until the PF is reloaded.
583
584 NOTE: Assigning a MAC address for a VF from the host will disable any
585 subsequent requests to change the MAC address from within the VM. This is a
586 security feature. The VM is not aware of this restriction, so if this is
587 attempted in the VM, it will trigger MDD events.
588
589
590 Trusted VFs and VF Promiscuous Mode
591 -----------------------------------
592 This feature allows you to designate a particular VF as trusted and allows that
593 trusted VF to request selective promiscuous mode on the Physical Function (PF).
594
595 To set a VF as trusted or untrusted, enter the following command in the
596 Hypervisor::
597
598 # ip link set dev <ethX> vf 1 trust [on|off]
599
600 NOTE: It's important to set the VF to trusted before setting promiscuous mode.
601 If the VM is not trusted, the PF will ignore promiscuous mode requests from the
602 VF. If the VM becomes trusted after the VF driver is loaded, you must make a
603 new request to set the VF to promiscuous.
604
605 Once the VF is designated as trusted, use the following commands in the VM to
606 set the VF to promiscuous mode.
607
608 For promiscuous all::
609
610 # ip link set <ethX> promisc on
611 Where <ethX> is a VF interface in the VM
612
613 For promiscuous Multicast::
614
615 # ip link set <ethX> allmulticast on
616 Where <ethX> is a VF interface in the VM
617
618 NOTE: By default, the ethtool private flag vf-true-promisc-support is set to
619 "off," meaning that promiscuous mode for the VF will be limited. To set the
620 promiscuous mode for the VF to true promiscuous and allow the VF to see all
621 ingress traffic, use the following command::
622
623 # ethtool --set-priv-flags <ethX> vf-true-promisc-support on
624
625 The vf-true-promisc-support private flag does not enable promiscuous mode;
626 rather, it designates which type of promiscuous mode (limited or true) you will
627 get when you enable promiscuous mode using the ip link commands above. Note
628 that this is a global setting that affects the entire device. However, the
629 vf-true-promisc-support private flag is only exposed to the first PF of the
630 device. The PF remains in limited promiscuous mode regardless of the
631 vf-true-promisc-support setting.
632
633 Next, add a VLAN interface on the VF interface. For example::
634
635 # ip link add link eth2 name eth2.100 type vlan id 100
636
637 Note that the order in which you set the VF to promiscuous mode and add the
638 VLAN interface does not matter (you can do either first). The result in this
639 example is that the VF will get all traffic that is tagged with VLAN 100.
640
641
642 Malicious Driver Detection (MDD) for VFs
643 ----------------------------------------
644 Some Intel Ethernet devices use Malicious Driver Detection (MDD) to detect
645 malicious traffic from the VF and disable Tx/Rx queues or drop the offending
646 packet until a VF driver reset occurs. You can view MDD messages in the PF's
647 system log using the dmesg command.
648
649 - If the PF driver logs MDD events from the VF, confirm that the correct VF
650 driver is installed.
651 - To restore functionality, you can manually reload the VF or VM or enable
652 automatic VF resets.
653 - When automatic VF resets are enabled, the PF driver will immediately reset
654 the VF and reenable queues when it detects MDD events on the receive path.
655 - If automatic VF resets are disabled, the PF will not automatically reset the
656 VF when it detects MDD events.
657
658 To enable or disable automatic VF resets, use the following command::
659
660 # ethtool --set-priv-flags <ethX> mdd-auto-reset-vf on|off
661
662
663 MAC and VLAN Anti-Spoofing Feature for VFs
664 ------------------------------------------
665 When a malicious driver on a Virtual Function (VF) interface attempts to send a
666 spoofed packet, it is dropped by the hardware and not transmitted.
667
668 NOTE: This feature can be disabled for a specific VF::
669
670 # ip link set <ethX> vf <vf id> spoofchk {off|on}
671
672
673 Jumbo Frames
674 ------------
675 Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
676 to a value larger than the default value of 1500.
677
678 Use the ifconfig command to increase the MTU size. For example, enter the
679 following where <ethX> is the interface number::
680
681 # ifconfig <ethX> mtu 9000 up
682
683 Alternatively, you can use the ip command as follows::
684
685 # ip link set mtu 9000 dev <ethX>
686 # ip link set up dev <ethX>
687
688 This setting is not saved across reboots.
689
690
691 NOTE: The maximum MTU setting for jumbo frames is 9702. This corresponds to the
692 maximum jumbo frame size of 9728 bytes.
693
694 NOTE: This driver will attempt to use multiple page sized buffers to receive
695 each jumbo packet. This should help to avoid buffer starvation issues when
696 allocating receive packets.
697
698 NOTE: Packet loss may have a greater impact on throughput when you use jumbo
699 frames. If you observe a drop in performance after enabling jumbo frames,
700 enabling flow control may mitigate the issue.
701
702
703 Speed and Duplex Configuration
704 ------------------------------
705 In addressing speed and duplex configuration issues, you need to distinguish
706 between copper-based adapters and fiber-based adapters.
707
708 In the default mode, an Intel(R) Ethernet Network Adapter using copper
709 connections will attempt to auto-negotiate with its link partner to determine
710 the best setting. If the adapter cannot establish link with the link partner
711 using auto-negotiation, you may need to manually configure the adapter and link
712 partner to identical settings to establish link and pass packets. This should
713 only be needed when attempting to link with an older switch that does not
714 support auto-negotiation or one that has been forced to a specific speed or
715 duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds
716 and higher cannot be forced. Use the autonegotiation advertising setting to
717 manually set devices for 1 Gbps and higher.
718
719 Speed, duplex, and autonegotiation advertising are configured through the
720 ethtool utility. For the latest version, download and install ethtool from the
721 following website:
722
723 https://kernel.org/pub/software/network/ethtool/
724
725 To see the speed configurations your device supports, run the following::
726
727 # ethtool <ethX>
728
729 Caution: Only experienced network administrators should force speed and duplex
730 or change autonegotiation advertising manually. The settings at the switch must
731 always match the adapter settings. Adapter performance may suffer or your
732 adapter may not operate if you configure the adapter differently from your
733 switch.
734
735
736 Data Center Bridging (DCB)
737 --------------------------
738 NOTE: The kernel assumes that TC0 is available, and will disable Priority Flow
739 Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
740 enabled when setting up DCB on your switch.
741
742 DCB is a configuration Quality of Service implementation in hardware. It uses
743 the VLAN priority tag (802.1p) to filter traffic. That means that there are 8
744 different priorities that traffic can be filtered into. It also enables
745 priority flow control (802.1Qbb) which can limit or eliminate the number of
746 dropped packets during network stress. Bandwidth can be allocated to each of
747 these priorities, which is enforced at the hardware level (802.1Qaz).
748
749 DCB is normally configured on the network using the DCBX protocol (802.1Qaz), a
750 specialization of LLDP (802.1AB). The ice driver supports the following
751 mutually exclusive variants of DCBX support:
752
753 1) Firmware-based LLDP Agent
754 2) Software-based LLDP Agent
755
756 In firmware-based mode, firmware intercepts all LLDP traffic and handles DCBX
757 negotiation transparently for the user. In this mode, the adapter operates in
758 "willing" DCBX mode, receiving DCB settings from the link partner (typically a
759 switch). The local user can only query the negotiated DCB configuration. For
760 information on configuring DCBX parameters on a switch, please consult the
761 switch manufacturer's documentation.
762
763 In software-based mode, LLDP traffic is forwarded to the network stack and user
764 space, where a software agent can handle it. In this mode, the adapter can
765 operate in either "willing" or "nonwilling" DCBX mode and DCB configuration can
766 be both queried and set locally. This mode requires the FW-based LLDP Agent to
767 be disabled.
768
769 NOTE:
770
771 - You can enable and disable the firmware-based LLDP Agent using an ethtool
772 private flag. Refer to the "FW-LLDP (Firmware Link Layer Discovery Protocol)"
773 section in this README for more information.
774 - In software-based DCBX mode, you can configure DCB parameters using software
775 LLDP/DCBX agents that interface with the Linux kernel's DCB Netlink API. We
776 recommend using OpenLLDP as the DCBX agent when running in software mode. For
777 more information, see the OpenLLDP man pages and
778 https://github.com/intel/openlldp.
779 - The driver implements the DCB netlink interface layer to allow the user space
780 to communicate with the driver and query DCB configuration for the port.
781 - iSCSI with DCB is not supported.
782
783
784 FW-LLDP (Firmware Link Layer Discovery Protocol)
785 ------------------------------------------------
786 Use ethtool to change FW-LLDP settings. The FW-LLDP setting is per port and
787 persists across boots.
788
789 To enable LLDP::
790
791 # ethtool --set-priv-flags <ethX> fw-lldp-agent on
792
793 To disable LLDP::
794
795 # ethtool --set-priv-flags <ethX> fw-lldp-agent off
796
797 To check the current LLDP setting::
798
799 # ethtool --show-priv-flags <ethX>
800
801 NOTE: You must enable the UEFI HII "LLDP Agent" attribute for this setting to
802 take effect. If "LLDP AGENT" is set to disabled, you cannot enable it from the
803 OS.
804
805
806 Flow Control
807 ------------
808 Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
809 receiving and transmitting pause frames for ice. When transmit is enabled,
810 pause frames are generated when the receive packet buffer crosses a predefined
811 threshold. When receive is enabled, the transmit unit will halt for the time
812 delay specified when a pause frame is received.
813
814 NOTE: You must have a flow control capable link partner.
815
816 Flow Control is disabled by default.
817
818 Use ethtool to change the flow control settings.
819
820 To enable or disable Rx or Tx Flow Control::
821
822 # ethtool -A <ethX> rx <on|off> tx <on|off>
823
824 Note: This command only enables or disables Flow Control if auto-negotiation is
825 disabled. If auto-negotiation is enabled, this command changes the parameters
826 used for auto-negotiation with the link partner.
827
828 Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending
829 on your device, you may not be able to change the auto-negotiation setting.
830
831 NOTE:
832
833 - The ice driver requires flow control on both the port and link partner. If
834 flow control is disabled on one of the sides, the port may appear to hang on
835 heavy traffic.
836 - You may encounter issues with link-level flow control (LFC) after disabling
837 DCB. The LFC status may show as enabled but traffic is not paused. To resolve
838 this issue, disable and reenable LFC using ethtool::
839
840 # ethtool -A <ethX> rx off tx off
841 # ethtool -A <ethX> rx on tx on
842
843
844 NAPI
845 ----
846
847 This driver supports NAPI (Rx polling mode).
848
849 See :ref:`Documentation/networking/napi.rst <napi>` for more information.
850
851 MACVLAN
852 -------
853 This driver supports MACVLAN. Kernel support for MACVLAN can be tested by
854 checking if the MACVLAN driver is loaded. You can run 'lsmod | grep macvlan' to
855 see if the MACVLAN driver is loaded or run 'modprobe macvlan' to try to load
856 the MACVLAN driver.
857
858 NOTE:
859
860 - In passthru mode, you can only set up one MACVLAN device. It will inherit the
861 MAC address of the underlying PF (Physical Function) device.
862
863
864 IEEE 802.1ad (QinQ) Support
865 ---------------------------
866 The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
867 IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
868 "tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
869 allow L2 tunneling and the ability to segregate traffic within a particular
870 VLAN ID, among other uses.
871
872 NOTES:
873
874 - Receive checksum offloads and VLAN acceleration are not supported for 802.1ad
875 (QinQ) packets.
876
877 - 0x88A8 traffic will not be received unless VLAN stripping is disabled with
878 the following command::
879
880 # ethtool -K <ethX> rxvlan off
881
882 - 0x88A8/0x8100 double VLANs cannot be used with 0x8100 or 0x8100/0x8100 VLANS
883 configured on the same port. 0x88a8/0x8100 traffic will not be received if
884 0x8100 VLANs are configured.
885
886 - The VF can only transmit 0x88A8/0x8100 (i.e., 802.1ad/802.1Q) traffic if:
887
888 1) The VF is not assigned a port VLAN.
889 2) spoofchk is disabled from the PF. If you enable spoofchk, the VF will
890 not transmit 0x88A8/0x8100 traffic.
891
892 - The VF may not receive all network traffic based on the Inner VLAN header
893 when VF true promiscuous mode (vf-true-promisc-support) and double VLANs are
894 enabled in SR-IOV mode.
895
896 The following are examples of how to configure 802.1ad (QinQ)::
897
898 # ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
899 # ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371
900
901 Where "24" and "371" are example VLAN IDs.
902
903
904 Tunnel/Overlay Stateless Offloads
905 ---------------------------------
906 Supported tunnels and overlays include VXLAN, GENEVE, and others depending on
907 hardware and software configuration. Stateless offloads are enabled by default.
908
909 To view the current state of all offloads::
910
911 # ethtool -k <ethX>
912
913
914 UDP Segmentation Offload
915 ------------------------
916 Allows the adapter to offload transmit segmentation of UDP packets with
917 payloads up to 64K into valid Ethernet frames. Because the adapter hardware is
918 able to complete data segmentation much faster than operating system software,
919 this feature may improve transmission performance.
920 In addition, the adapter may use fewer CPU resources.
921
922 NOTE:
923
924 - The application sending UDP packets must support UDP segmentation offload.
925
926 To enable/disable UDP Segmentation Offload, issue the following command::
927
928 # ethtool -K <ethX> tx-udp-segmentation [off|on]
929
930 PTP pin interface
931 -----------------
932 All adapters support standard PTP pin interface. SDPs (Software Definable Pin)
933 are single ended pins with both periodic output and external timestamp
934 supported. There are also specific differential input/output pins (TIME_SYNC,
935 1PPS) with only one of the functions supported.
936
937 There are adapters with DPLL, where pins are connected to the DPLL instead of
938 being exposed on the board. You have to be aware that in those configurations,
939 only SDP pins are exposed and each pin has its own fixed direction.
940 To see input signal on those PTP pins, you need to configure DPLL properly.
941 Output signal is only visible on DPLL and to send it to the board SMA/U.FL pins,
942 DPLL output pins have to be manually configured.
943
944 GNSS module
945 -----------
946 Requires kernel compiled with CONFIG_GNSS=y or CONFIG_GNSS=m.
947 Allows user to read messages from the GNSS hardware module and write supported
948 commands. If the module is physically present, a GNSS device is spawned:
949 ``/dev/gnss<id>``.
950 The protocol of write command is dependent on the GNSS hardware module as the
951 driver writes raw bytes by the GNSS object to the receiver through i2c. Please
952 refer to the hardware GNSS module documentation for configuration details.
953
954
955 Firmware (FW) logging
956 ---------------------
957 The driver supports FW logging via the debugfs interface on PF 0 only. The FW
958 running on the NIC must support FW logging; if the FW doesn't support FW logging
959 the 'fwlog' file will not get created in the ice debugfs directory.
960
961 Module configuration
962 ~~~~~~~~~~~~~~~~~~~~
963 Firmware logging is configured on a per module basis. Each module can be set to
964 a value independent of the other modules (unless the module 'all' is specified).
965 The modules will be instantiated under the 'fwlog/modules' directory.
966
967 The user can set the log level for a module by writing to the module file like
968 this::
969
970 # echo <log_level> > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/<module>
971
972 where
973
974 * log_level is a name as described below. Each level includes the
975 messages from the previous/lower level
976
977 * none
978 * error
979 * warning
980 * normal
981 * verbose
982
983 * module is a name that represents the module to receive events for. The
984 module names are
985
986 * general
987 * ctrl
988 * link
989 * link_topo
990 * dnl
991 * i2c
992 * sdp
993 * mdio
994 * adminq
995 * hdma
996 * lldp
997 * dcbx
998 * dcb
999 * xlr
1000 * nvm
1001 * auth
1002 * vpd
1003 * iosf
1004 * parser
1005 * sw
1006 * scheduler
1007 * txq
1008 * rsvd
1009 * post
1010 * watchdog
1011 * task_dispatch
1012 * mng
1013 * synce
1014 * health
1015 * tsdrv
1016 * pfreg
1017 * mdlver
1018 * all
1020 The name 'all' is special and allows the user to set all of the modules to the
1021 specified log_level or to read the log_level of all of the modules.
1023 Example usage to configure the modules
1024 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1026 To set a single module to 'verbose'::
1028 # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link
1030 To set multiple modules then issue the command multiple times::
1032 # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link
1033 # echo warning > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/ctrl
1034 # echo none > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/dcb
1036 To set all the modules to the same value::
1038 # echo normal > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all
1040 To read the log_level of a specific module (e.g. module 'general')::
1042 # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/general
1044 To read the log_level of all the modules::
1046 # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all
1048 Enabling FW log
1049 ~~~~~~~~~~~~~~~
1050 Configuring the modules indicates to the FW that the configured modules should
1051 generate events that the driver is interested in, but it **does not** send the
1052 events to the driver until the enable message is sent to the FW. To do this
1053 the user can write a 1 (enable) or 0 (disable) to 'fwlog/enable'. An example
1054 is::
1056 # echo 1 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/enable
1058 Retrieving FW log data
1059 ~~~~~~~~~~~~~~~~~~~~~~
1060 The FW log data can be retrieved by reading from 'fwlog/data'. The user can
1061 write any value to 'fwlog/data' to clear the data. The data can only be cleared
1062 when FW logging is disabled. The FW log data is a binary file that is sent to
1063 Intel and used to help debug user issues.
1065 An example to read the data is::
1067 # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data > fwlog.bin
1069 An example to clear the data is::
1071 # echo 0 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data
1073 Changing how often the log events are sent to the driver
1074 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1075 The driver receives FW log data from the Admin Receive Queue (ARQ). The
1076 frequency that the FW sends the ARQ events can be configured by writing to
1077 'fwlog/nr_messages'. The range is 1-128 (1 means push every log message, 128
1078 means push only when the max AQ command buffer is full). The suggested value is
1079 10. The user can see what the value is configured to by reading
1080 'fwlog/nr_messages'. An example to set the value is::
1082 # echo 50 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/nr_messages
1084 Configuring the amount of memory used to store FW log data
1085 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1086 The driver stores FW log data within the driver. The default size of the memory
1087 used to store the data is 1MB. Some use cases may require more or less data so
1088 the user can change the amount of memory that is allocated for FW log data.
1089 To change the amount of memory then write to 'fwlog/log_size'. The value must be
1090 one of: 128K, 256K, 512K, 1M, or 2M. FW logging must be disabled to change the
1091 value. An example of changing the value is::
1093 # echo 128K > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/log_size
1096 Performance Optimization
1097 ========================
1098 Driver defaults are meant to fit a wide variety of workloads, but if further
1099 optimization is required, we recommend experimenting with the following
1100 settings.
1103 Rx Descriptor Ring Size
1104 -----------------------
1105 To reduce the number of Rx packet discards, increase the number of Rx
1106 descriptors for each Rx ring using ethtool.
1108 Check if the interface is dropping Rx packets due to buffers being full
1109 (rx_dropped.nic can mean that there is no PCIe bandwidth)::
1111 # ethtool -S <ethX> | grep "rx_dropped"
1113 If the previous command shows drops on queues, it may help to increase
1114 the number of descriptors using 'ethtool -G'::
1116 # ethtool -G <ethX> rx <N>
1117 Where <N> is the desired number of ring entries/descriptors
1119 This can provide temporary buffering for issues that create latency while
1120 the CPUs process descriptors.
1123 Interrupt Rate Limiting
1124 -----------------------
1125 This driver supports an adaptive interrupt throttle rate (ITR) mechanism that
1126 is tuned for general workloads. The user can customize the interrupt rate
1127 control for specific workloads, via ethtool, adjusting the number of
1128 microseconds between interrupts.
1130 To set the interrupt rate manually, you must disable adaptive mode::
1132 # ethtool -C <ethX> adaptive-rx off adaptive-tx off
1134 For lower CPU utilization:
1136 Disable adaptive ITR and lower Rx and Tx interrupts. The examples below
1137 affect every queue of the specified interface.
1139 Setting rx-usecs and tx-usecs to 80 will limit interrupts to about
1140 12,500 interrupts per second per queue::
1142 # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80 tx-usecs 80
1144 For reduced latency:
1146 Disable adaptive ITR and ITR by setting rx-usecs and tx-usecs to 0
1147 using ethtool::
1149 # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0
1151 Per-queue interrupt rate settings:
1153 The following examples are for queues 1 and 3, but you can adjust other
1154 queues.
1156 To disable Rx adaptive ITR and set static Rx ITR to 10 microseconds or
1157 about 100,000 interrupts/second, for queues 1 and 3::
1159 # ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off
1160 rx-usecs 10
1162 To show the current coalesce settings for queues 1 and 3::
1164 # ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce
1166 Bounding interrupt rates using rx-usecs-high:
1168 :Valid Range: 0-236 (0=no limit)
1170 The range of 0-236 microseconds provides an effective range of 4,237 to
1171 250,000 interrupts per second. The value of rx-usecs-high can be set
1172 independently of rx-usecs and tx-usecs in the same ethtool command, and is
1173 also independent of the adaptive interrupt moderation algorithm. The
1174 underlying hardware supports granularity in 4-microsecond intervals, so
1175 adjacent values may result in the same interrupt rate.
1177 The following command would disable adaptive interrupt moderation, and allow
1178 a maximum of 5 microseconds before indicating a receive or transmit was
1179 complete. However, instead of resulting in as many as 200,000 interrupts per
1180 second, it limits total interrupts per second to 50,000 via the rx-usecs-high
1181 parameter.
1183 ::
1185 # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs-high 20
1186 rx-usecs 5 tx-usecs 5
1189 Virtualized Environments
1190 ------------------------
1191 In addition to the other suggestions in this section, the following may be
1192 helpful to optimize performance in VMs.
1194 Using the appropriate mechanism (vcpupin) in the VM, pin the CPUs to
1195 individual LCPUs, making sure to use a set of CPUs included in the
1196 device's local_cpulist: ``/sys/class/net/<ethX>/device/local_cpulist``.
1198 Configure as many Rx/Tx queues in the VM as available. (See the iavf driver
1199 documentation for the number of queues supported.) For example::
1201 # ethtool -L <virt_interface> rx <max> tx <max>
1204 Support
1205 =======
1206 For general information, go to the Intel support website at:
1207 https://www.intel.com/support/
1209 If an issue is identified with the released source code on a supported kernel
1210 with a supported adapter, email the specific information related to the issue
1211 to intel-wired-lan@lists.osuosl.org.
1214 Trademarks
1215 ==========
1216 Intel is a trademark or registered trademark of Intel Corporation or its
1217 subsidiaries in the United States and/or other countries.
1219 * Other names and brands may be claimed as the property of others.

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

개요와 adapter 식별

1-41

이 문서는 `GPL-2.0+` 라이선스를 따릅니다.

Intel(R) Ethernet Controller 800 Series용 Linux Base Driver

Intel ice Linux driver.

Copyright(c) 2018-2021 Intel Corporation.

목차

  • 개요
  • Adapter 식별
  • 중요 참고사항
  • 추가 기능과 configuration
  • Performance 최적화

이 driver와 연결되는 Virtual Function(VF) driver는 iavf입니다.

driver 정보는 ethtool과 lspci로 확인할 수 있습니다.

hardware requirement는 Intel adapter와 함께 제공된 문서를 참고하십시오. 기재된 모든 hardware requirement는 Linux 사용에도 적용됩니다.

이 driver는 XDP(Express Data Path)와 AF_XDP zero-copy를 지원합니다. frame 크기가 3KB를 넘으면 XDP가 차단됩니다.

Adapter 식별

adapter 식별 방법과 최신 Intel network driver는 Intel Support website `https://www.intel.com/support`를 참고하십시오.

중요 참고사항

.. SPDX-License-Identifier: GPL-2.0+

=================================================================
Linux Base Driver for the Intel(R) Ethernet Controller 800 Series
=================================================================

Intel ice Linux driver.
Copyright(c) 2018-2021 Intel Corporation.

Contents
========

- Overview
- Identifying Your Adapter
- Important Notes
- Additional Features & Configurations
- Performance Optimization


The associated Virtual Function (VF) driver for this driver is iavf.

Driver information can be obtained using ethtool and lspci.

For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.

This driver supports XDP (Express Data Path) and AF_XDP zero-copy. Note that
XDP is blocked for frame sizes larger than 3KB.


Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
https://www.intel.com/support


Important Notes
===============

Receive stress, SR-IOV 보안과 active VM

42-86

receive stress에서 packet drop이 발생할 수 있음

Intel(R) Ethernet Controller 800 Series 기반 device는 PCIe와 DMA transaction 중 제한된 system latency를 견디도록 설계되었습니다. transaction이 허용 latency보다 오래 걸리면 device와 관련 memory에서 packet을 buffering하는 시간이 줄어 packet drop이 생길 수 있습니다. 표준 workload에서는 보통 throughput과 performance에 눈에 띄는 영향을 주지 않습니다.

drop이 workload에 영향을 준다면 다음 조치를 시도하십시오.

  • platform vendor 권장에 따라 physical memory를 high-performance 구성으로 맞춥니다. 흔한 권장은 모든 channel에 DIMM module 하나씩 장착하는 것입니다.
  • BIOS/UEFI에서 `Performance` profile을 선택합니다.
  • distribution이 제공하는 `tuned` 같은 tool로 workload에 맞는 kernel 설정을 적용합니다.

network 보안을 높이기 위한 SR-IOV 구성

SR-IOV를 지원하는 Intel adapter의 virtualized environment에서는 VF가 악의적으로 동작할 수 있습니다. software가 생성한 IEEE 802.3x link flow-control, IEEE 802.1Qbb priority-based flow-control 같은 layer 2 frame은 예상된 traffic이 아니며 host와 virtual switch 사이 traffic을 throttle해 성능을 낮출 수 있습니다.

의도하지 않은 traffic stream을 격리하고 잠재적으로 악의적인 frame을 drop하려면 PF의 administrative interface에서 모든 SR-IOV port에 VLAN tagging을 구성하십시오. 자세한 command는 뒤의 `Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports` 절을 참고합니다.

active VM에 bind된 VF가 있으면 port driver를 unload하지 마십시오.

active VM에 bind된 VF가 있는 port의 driver를 unload하면 port가 정지한 것처럼 보입니다. VM이 종료되거나 VF를 release하면 command가 완료됩니다.

Packet drops may occur under receive stress
-------------------------------------------
Devices based on the Intel(R) Ethernet Controller 800 Series are designed to
tolerate a limited amount of system latency during PCIe and DMA transactions.
If these transactions take longer than the tolerated latency, it can impact the
length of time the packets are buffered in the device and associated memory,
which may result in dropped packets. These packets drops typically do not have
a noticeable impact on throughput and performance under standard workloads.

If these packet drops appear to affect your workload, the following may improve
the situation:

1) Make sure that your system's physical memory is in a high-performance
   configuration, as recommended by the platform vendor. A common
   recommendation is for all channels to be populated with a single DIMM
   module.
2) In your system's BIOS/UEFI settings, select the "Performance" profile.
3) Your distribution may provide tools like "tuned," which can help tweak
   kernel settings to achieve better standard settings for different workloads.


Configuring SR-IOV for improved network security
------------------------------------------------
In a virtualized environment, on Intel(R) Ethernet Network Adapters that
support SR-IOV, the virtual function (VF) may be subject to malicious behavior.
Software-generated layer two frames, like IEEE 802.3x (link flow control), IEEE
802.1Qbb (priority based flow-control), and others of this type, are not
expected and can throttle traffic between the host and the virtual switch,
reducing performance. To resolve this issue, and to ensure isolation from
unintended traffic streams, configure all SR-IOV enabled ports for VLAN tagging
from the administrative interface on the PF. This configuration allows
unexpected, and potentially malicious, frames to be dropped.

See "Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports" later in this
README for configuration instructions.


Do not unload port driver if VF with active VM is bound to it
-------------------------------------------------------------
Do not unload a port's driver if a Virtual Function (VF) with an active Virtual
Machine (VM) is bound to it. Doing so will cause the port to appear to hang.
Once the VM shuts down, or otherwise releases the VF, the command will
complete.

ethtool, reset과 link message

87-146

추가 기능과 configuration

ethtool

driver는 configuration, 진단과 통계 표시를 위해 ethtool interface를 사용합니다. 최신 ethtool은 `https://kernel.org/pub/software/network/ethtool/`에서 받을 수 있습니다.

참고: device가 4-byte CRC를 제거하므로 ethtool의 `rx_bytes`와 Netdev의 `rx_bytes`가 다릅니다. 차이는 `4 x Rx packet 수`입니다. packet이 10개이고 Netdev가 X를 표시하면 hardware statistic인 ethtool은 `X+40`을 표시합니다.

ethtool reset

driver는 세 종류의 reset을 지원합니다.

  • PF reset: 해당 PF 관련 component만 reset하며 다른 PF에 영향이 없습니다.
  • CORE reset: adapter 전체와 모든 PF를 reset합니다.
  • GLOBAL reset: CORE와 같고 MAC 및 PHY component도 다시 initialize합니다.

각 reset은 다음 ethtool reset flag에 대응합니다.

# PF reset
ethtool --reset <ethX> irq dma filter offload

# CORE reset
ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared ram-shared

# GLOBAL reset
ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared mac-shared phy-shared ram-shared

# switchdev mode에서 port representor를 통한 VF reset
ethtool --reset <repr> irq dma filter offload

Link message 보기

distribution이 system message를 제한하면 link message가 console에 표시되지 않습니다. network driver link message를 보려면 dmesg level을 8로 설정합니다.

# dmesg -n 8

이 설정은 reboot 후 유지되지 않습니다.

Additional Features and Configurations
======================================

ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest ethtool
version is required for this functionality. Download it at:
https://kernel.org/pub/software/network/ethtool/

NOTE: The rx_bytes value of ethtool does not match the rx_bytes value of
Netdev, due to the 4-byte CRC being stripped by the device. The difference
between the two rx_bytes values will be 4 x the number of Rx packets. For
example, if Rx packets are 10 and Netdev (software statistics) displays
rx_bytes as "X", then ethtool (hardware statistics) will display rx_bytes as
"X+40" (4 bytes CRC x 10 packets).

ethtool reset
-------------
The driver supports 3 types of resets:

- PF reset - resets only components associated with the given PF, does not
  impact other PFs

- CORE reset - whole adapter is affected, reset all PFs

- GLOBAL reset - same as CORE but mac and phy components are also reinitialized

These are mapped to ethtool reset flags as follow:

- PF reset:

  # ethtool --reset <ethX> irq dma filter offload

- CORE reset:

  # ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared \
  ram-shared

- GLOBAL reset:

  # ethtool --reset <ethX> irq-shared dma-shared filter-shared offload-shared \
  mac-shared phy-shared ram-shared

In switchdev mode you can reset a VF using port representor:

  # ethtool --reset <repr> irq dma filter offload


Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
your console, set dmesg to eight by entering the following::

  # dmesg -n 8

NOTE: This setting is not saved across reboots.

Dynamic Device Personalization

147-220

Dynamic Device Personalization

DDP는 runtime에 profile package를 적용해 device packet-processing pipeline을 바꿉니다. 새 protocol 지원 추가, 기존 protocol 변경, default 설정 변경에 사용할 수 있고 reboot 없이 rollback할 수 있습니다.

DDP package는 device initialize 중 load됩니다. driver는 firmware root, 보통 `/lib/firmware/` 또는 `/lib/firmware/updates/` 아래의 `intel/ice/ddp/ice.pkg`를 찾아 유효한 package인지 확인합니다.

distribution이 최신 DDP file을 제공하는 것이 일반적입니다. `ice.pkg`가 없으면 linux-firmware repository 또는 intel.com에서 구할 수 있습니다.

DDP package를 load하지 못하면 device는 Safe Mode로 들어갑니다. Safe Mode는 advanced·performance feature를 끄고 기본 traffic, NVM update, 새 driver 또는 DDP package download 같은 최소 기능만 제공합니다. 영향은 해당 PF에만 국한됩니다.

DDP 운용 참고사항

  • package 문제가 있으면 log를 확인하고 새 driver 또는 DDP package를 받습니다.
  • `ice.pkg`는 default DDP package를 가리키는 symbolic link입니다.
  • PF driver가 하나라도 load된 상태에서는 DDP를 update할 수 없습니다. 모든 PF를 unload한 뒤 새 package로 driver를 reload합니다.
  • device마다 처음 load된 PF만 해당 device에 package를 download할 수 있습니다.

system의 physical device마다 고유 DDP package를 설치하는 절차는 다음과 같습니다.

  • 원하는 DDP package를 받습니다.
  • file을 `ice-xxxxxxxxxxxxxxxx.pkg`로 바꿉니다. x는 leading zero를 포함한 lowercase 64-bit PCIe device serial number입니다.
  • PCI bus address에서 `lspci -vv -s af:00.0 | grep -i Serial`로 serial을 확인하고 `awk`와 `sed s/-//g`로 dash를 제거할 수 있습니다.
  • renamed package를 `/lib/firmware/updates/intel/ice/ddp/`에 복사합니다. directory가 없으면 만듭니다.
  • device의 모든 PF를 unload합니다.
  • 새 package로 driver를 reload합니다.
lspci -vv -s af:00.0 | grep -i Serial
lspci -vv -s af:00.0 | grep -i Serial | awk '{print $7}' | sed s/-//g

device-specific DDP package가 있으면 default `ice.pkg`보다 우선합니다.

Dynamic Device Personalization
------------------------------
Dynamic Device Personalization (DDP) allows you to change the packet processing
pipeline of a device by applying a profile package to the device at runtime.
Profiles can be used to, for example, add support for new protocols, change
existing protocols, or change default settings. DDP profiles can also be rolled
back without rebooting the system.

The DDP package loads during device initialization. The driver looks for
``intel/ice/ddp/ice.pkg`` in your firmware root (typically ``/lib/firmware/``
or ``/lib/firmware/updates/``) and checks that it contains a valid DDP package
file.

NOTE: Your distribution should likely have provided the latest DDP file, but if
ice.pkg is missing, you can find it in the linux-firmware repository or from
intel.com.

If the driver is unable to load the DDP package, the device will enter Safe
Mode. Safe Mode disables advanced and performance features and supports only
basic traffic and minimal functionality, such as updating the NVM or
downloading a new driver or DDP package. Safe Mode only applies to the affected
physical function and does not impact any other PFs. See the "Intel(R) Ethernet
Adapters and Devices User Guide" for more details on DDP and Safe Mode.

NOTES:

- If you encounter issues with the DDP package file, you may need to download
  an updated driver or DDP package file. See the log messages for more
  information.

- The ice.pkg file is a symbolic link to the default DDP package file.

- You cannot update the DDP package if any PF drivers are already loaded. To
  overwrite a package, unload all PFs and then reload the driver with the new
  package.

- Only the first loaded PF per device can download a package for that device.

You can install specific DDP package files for different physical devices in
the same system. To install a specific DDP package file:

1. Download the DDP package file you want for your device.

2. Rename the file ice-xxxxxxxxxxxxxxxx.pkg, where 'xxxxxxxxxxxxxxxx' is the
   unique 64-bit PCI Express device serial number (in hex) of the device you
   want the package downloaded on. The filename must include the complete
   serial number (including leading zeros) and be all lowercase. For example,
   if the 64-bit serial number is b887a3ffffca0568, then the file name would be
   ice-b887a3ffffca0568.pkg.

   To find the serial number from the PCI bus address, you can use the
   following command::

     # lspci -vv -s af:00.0 | grep -i Serial
     Capabilities: [150 v1] Device Serial Number b8-87-a3-ff-ff-ca-05-68

   You can use the following command to format the serial number without the
   dashes::

     # lspci -vv -s af:00.0 | grep -i Serial | awk '{print $7}' | sed s/-//g
     b887a3ffffca0568

3. Copy the renamed DDP package file to
   ``/lib/firmware/updates/intel/ice/ddp/``. If the directory does not yet
   exist, create it before copying the file.

4. Unload all of the PFs on the device.

5. Reload the driver with the new package.

NOTE: The presence of a device-specific DDP package file overrides the loading
of the default DDP package file (ice.pkg).

Flow Director와 filter 규칙

221-345

Intel(R) Ethernet Flow Director

Flow Director는 다음 작업을 수행합니다.

  • flow에 따라 receive packet을 서로 다른 queue로 보냅니다.
  • platform의 flow routing을 정밀하게 제어합니다.
  • flow와 CPU core를 연결해 flow affinity를 제공합니다.

지원 flow type은 IPv4, TCPv4, UDPv4, SCTPv4, IPv6, TCPv6, UDPv6, SCTPv6입니다. 각 type에서 source/destination IP와 source/destination UDP/TCP/SCTP port를 하나 이상 조합할 수 있습니다.

ethtool `user-def`와 `mask` field로 user-defined 2-byte pattern과 offset을 기준으로 filter할 수 있습니다. L3/L4 flow type만 지원하며, 특정 type의 input set을 바꾸기 전에 그 type의 모든 Flow Director filter를 지워야 합니다.

Flow Director filter

지정한 특성과 일치하는 traffic을 queue로 보내며 ethtool ntuple interface로 제어합니다.

ethtool -K <ethX> ntuple <off|on>
ethtool -u <ethX>
ethtool -U <ethX> flow-type <type> src-ip <ip> [m <ip_mask>] dst-ip <ip> [m <ip_mask>] src-port <port> [m <port_mask>] dst-port <port> [m <port_mask>] action <queue>
ethtool -U <ethX> delete <N>

ntuple을 끄면 사용자가 program한 filter가 driver cache와 hardware에서 모두 flush됩니다. 다시 켠 뒤 필요한 filter를 다시 추가해야 합니다.

parameter 의미

  • `<type>`: ip4, tcp4, udp4, sctp4, ip6, tcp6, udp6, sctp6
  • `<ip>`: 일치시킬 IP address
  • `<ip_mask>`: IPv4 mask이며 inverted mask를 사용
  • `<port>`: 일치시킬 port number
  • `<port_mask>`: 16-bit inverted mask
  • `<queue>`: traffic을 보낼 queue, -1은 matching traffic drop
  • `<N>`: active filter 출력의 filter ID이며 추가할 때 `loc <N>`으로 지정할 수도 있음

queue 2로 보내는 TCPv4 rule, IP만 쓰는 rule과 user-def 예시는 다음과 같습니다.

ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]
ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip 192.168.10.2 action 2 [loc 1]
ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip 192.168.10.2 user-def 0x4FFFF action 2 [loc 1]

`user-def 0x4FFFF`는 payload offset 4 bytes와 pattern `0xffff`를 뜻합니다. source subnet partial mask 예시도 문서에 있지만 ice driver는 field 일부만 matching하는 partial mask를 지원하지 않습니다.

같은 flow type에 program한 모든 filter는 동일한 matching input set을 써야 합니다. 같은 field에 서로 다른 값은 허용되지만 한 device에서 서로 다른 field를 쓰는 두 tcp4 filter는 허용되지 않으며 둘째 command가 실패합니다.

Intel(R) Ethernet Flow Director
-------------------------------
The Intel Ethernet Flow Director performs the following tasks:

- Directs receive packets according to their flows to different queues
- Enables tight control on routing a flow in the platform
- Matches flows and CPU cores for flow affinity

NOTE: This driver supports the following flow types:

- IPv4
- TCPv4
- UDPv4
- SCTPv4
- IPv6
- TCPv6
- UDPv6
- SCTPv6

Each flow type supports valid combinations of IP addresses (source or
destination) and UDP/TCP/SCTP ports (source and destination). You can supply
only a source IP address, a source IP address and a destination port, or any
combination of one or more of these four parameters.

NOTE: This driver allows you to filter traffic based on a user-defined flexible
two-byte pattern and offset by using the ethtool user-def and mask fields. Only
L3 and L4 flow types are supported for user-defined flexible filters. For a
given flow type, you must clear all Intel Ethernet Flow Director filters before
changing the input set (for that flow type).


Flow Director Filters
---------------------
Flow Director filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To enable
or disable the Intel Ethernet Flow Director and these filters::

  # ethtool -K <ethX> ntuple <off|on>

NOTE: When you disable ntuple filters, all the user programmed filters are
flushed from the driver cache and hardware. All needed filters must be re-added
when ntuple is re-enabled.

To display all of the active filters::

  # ethtool -u <ethX>

To add a new filter::

  # ethtool -U <ethX> flow-type <type> src-ip <ip> [m <ip_mask>] dst-ip <ip>
  [m <ip_mask>] src-port <port> [m <port_mask>] dst-port <port> [m <port_mask>]
  action <queue>

  Where:
    <ethX> - the Ethernet device to program
    <type> - can be ip4, tcp4, udp4, sctp4, ip6, tcp6, udp6, sctp6
    <ip> - the IP address to match on
    <ip_mask> - the IPv4 address to mask on
              NOTE: These filters use inverted masks.
    <port> - the port number to match on
    <port_mask> - the 16-bit integer for masking
              NOTE: These filters use inverted masks.
    <queue> - the queue to direct traffic toward (-1 discards the
              matched traffic)

To delete a filter::

  # ethtool -U <ethX> delete <N>

  Where <N> is the filter ID displayed when printing all the active filters,
  and may also have been specified using "loc <N>" when adding the filter.

EXAMPLES:

To add a filter that directs packet to queue 2::

  # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
  192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1]

To set a filter using only the source and destination IP address::

  # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
  192.168.10.2 action 2 [loc 1]

To set a filter based on a user-defined pattern and offset::

  # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \
  192.168.10.2 user-def 0x4FFFF action 2 [loc 1]

  where the value of the user-def field contains the offset (4 bytes) and
  the pattern (0xffff).

To match TCP traffic sent from 192.168.0.1, port 5300, directed to 192.168.0.5,
port 80, and then send it to queue 7::

  # ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5
  src-port 5300 dst-port 80 action 7

To add a TCPv4 filter with a partial mask for a source IP subnet::

  # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.0.0 m 0.255.255.255 dst-ip
  192.168.5.12 src-port 12600 dst-port 31 action 12

NOTES:

For each flow-type, the programmed filters must all have the same matching
input set. For example, issuing the following two commands is acceptable::

  # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
  # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10

Issuing the next two commands, however, is not acceptable, since the first
specifies src-ip and the second specifies dst-ip::

  # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7
  # ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10

The second command will fail with an error. You may program multiple filters
with the same fields, using different values, but, on one device, you may not
program two tcp4 filters with different matching fields.

The ice driver does not support matching on a subportion of a field, thus
partial mask fields are not supported.

Flexible byte filter와 RSS hash

346-425

Flex Byte Flow Director Filter

driver는 packet payload 안의 user-defined data도 matching할 수 있습니다. ethtool `user-def`의 상위 16 bit는 payload offset, 하위 16 bit는 2-byte flexible data입니다.

user-def bit layout
Bits의미
31-16packet payload 내부 offset
15-02 bytes flexible data

원문의 bit-field 표를 같은 의미의 구조화 표로 옮겼습니다.

`user-def 0x4FFFF`는 payload 4 bytes 지점의 값이 `0xFFFF`인지 확인합니다. offset은 packet 시작이 아니라 payload 시작 기준입니다. `tcp4 ... user-def 0x8BEAF`는 TCP/IPv4 payload의 8 bytes 지점에서 `0xBEAF`를 찾습니다.

ICMP header는 header 4 bytes와 payload 4 bytes로 parse되므로 첫 payload byte를 matching하려면 offset에 4를 더해야 합니다. ip4 filter는 ICMP frame과 raw unknown ip4 frame을 모두 matching하며 후자의 payload는 IPv4 frame의 L3 payload입니다.

최대 offset은 64이며 hardware는 payload에서 최대 64 bytes만 읽습니다. flexible data가 2 bytes이고 payload byte 0에 align되어야 하므로 offset은 짝수여야 합니다.

flexible offset은 input set의 일부이므로 같은 type의 여러 filter에서 따로 program할 수 없습니다. data 값은 input set에 포함되지 않으므로 같은 offset에서 서로 다른 data를 matching하는 filter는 여러 개 둘 수 있습니다.

RSS Hash Flow

flow type별 hash byte와 Receive Side Scaling(RSS) hash 구성 option을 하나 이상 지정합니다.

ethtool -N <ethX> rx-flow-hash <type> <option>

type은 IPv4/IPv6의 tcp, udp와 GTP-C/GTP-U variant를 포함합니다. `gtpc*t`는 TEID 포함 GTP-C, `gtpu*e`는 extension header, `gtpu*u`와 `gtpu*d`는 PSC uplink/downlink를 나타냅니다.

  • `s`: Rx packet의 source IP address
  • `d`: destination IP address
  • `f`: Layer 4 header byte 0과 1
  • `n`: Layer 4 header byte 2와 3
  • `e`: GTP packet의 4-byte TEID
Flex Byte Flow Director Filters
-------------------------------
The driver also supports matching user-defined data within the packet payload.
This flexible data is specified using the "user-def" field of the ethtool
command in the following way:

.. table::

    ============================== ============================
    ``31    28    24    20    16`` ``15    12    8    4    0``
    ``offset into packet payload`` ``2 bytes of flexible data``
    ============================== ============================

For example,

::

  ... user-def 0x4FFFF ...

tells the filter to look 4 bytes into the payload and match that value against
0xFFFF. The offset is based on the beginning of the payload, and not the
beginning of the packet. Thus

::

  flow-type tcp4 ... user-def 0x8BEAF ...

would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the
TCP/IPv4 payload.

Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload.
Thus to match the first byte of the payload, you must actually add 4 bytes to
the offset. Also note that ip4 filters match both ICMP frames as well as raw
(unknown) ip4 frames, where the payload will be the L3 payload of the IP4
frame.

The maximum offset is 64. The hardware will only read up to 64 bytes of data
from the payload. The offset must be even because the flexible data is 2 bytes
long and must be aligned to byte 0 of the packet payload.

The user-defined flexible offset is also considered part of the input set and
cannot be programmed separately for multiple filters of the same type. However,
the flexible data is not part of the input set and multiple filters may use the
same offset but match against different data.


RSS Hash Flow
-------------
Allows you to set the hash bytes per flow type and any combination of one or
more options for Receive Side Scaling (RSS) hash byte configuration.

::

  # ethtool -N <ethX> rx-flow-hash <type> <option>

  Where <type> is:
    tcp4    signifying TCP over IPv4
    udp4    signifying UDP over IPv4
    gtpc4   signifying GTP-C over IPv4
    gtpc4t  signifying GTP-C (include TEID) over IPv4
    gtpu4   signifying GTP-U over IPV4
    gtpu4e  signifying GTP-U and Extension Header over IPV4
    gtpu4u  signifying GTP-U PSC Uplink over IPV4
    gtpu4d  signifying GTP-U PSC Downlink over IPV4
    tcp6    signifying TCP over IPv6
    udp6    signifying UDP over IPv6
    gtpc6   signifying GTP-C over IPv6
    gtpc6t  signifying GTP-C (include TEID) over IPv6
    gtpu6   signifying GTP-U over IPV6
    gtpu6e  signifying GTP-U and Extension Header over IPV6
    gtpu6u  signifying GTP-U PSC Uplink over IPV6
    gtpu6d  signifying GTP-U PSC Downlink over IPV6
  And <option> is one or more of:
    s     Hash on the IP source address of the Rx packet.
    d     Hash on the IP destination address of the Rx packet.
    f     Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet.
    n     Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet.
    e     Hash on GTP Packet on TEID (4bytes) of the Rx packet.

Accelerated Receive Flow Steering

426-507

Accelerated Receive Flow Steering(aRFS)

Intel 800 Series PF는 application이 실행 중이거나 해당 flow packet을 소비하는 CPU로 packet을 보내는 load-balancing mechanism인 aRFS를 지원합니다.

제약과 상호작용

  • ethtool에서 ntuple filtering을 활성화해야 합니다.
  • TCP/UDP over IPv4/IPv6의 nonfragmented packet만 지원합니다.
  • source/destination IP와 source/destination port로 구성한 Flow Director filter만 지원합니다.
  • aRFS와 ntuple은 같은 Flow Director를 공유하므로 공존할 수 있지만 request가 충돌하면 예상하지 못한 결과가 날 수 있습니다.

설정 절차

  • `ethtool -K <ethX> ntuple on`으로 Flow Director와 ntuple filter를 켭니다.
  • `/proc/sys/net/core/rps_sock_flow_entries`에 global flow table entry 수를 설정합니다.
  • 각 `rx-*/rps_flow_cnt`에 global entry를 Rx queue 수로 나눈 값을 기록합니다.
  • 다음 reboot 전까지 `systemctl stop irqbalance`로 IRQ balance daemon을 중지합니다.
  • `Documentation/core-api/irq/irq-affinity.rst`를 참고해 interrupt affinity를 구성합니다.
NUM_RPS_ENTRIES=16384
echo $NUM_RPS_ENTRIES > /proc/sys/net/core/rps_sock_flow_entries
NUM_RX_QUEUES=64
for file in /sys/class/net/$IFACE/queues/rx-*/rps_flow_cnt; do
  echo $(($NUM_RPS_ENTRIES/$NUM_RX_QUEUES)) > $file
done

`ethtool -K <ethX> ntuple off`로 aRFS를 끄면 ntuple filter와 software·hardware의 aRFS filter가 모두 지워집니다.

사용 예시는 `taskset -c 4 netserver`로 server application을 CPU 4에 고정한 뒤 aRFS가 구성된 server로 `netperf -H <Host IPv4 Address> -t TCP_STREAM` traffic을 보내는 것입니다.

Accelerated Receive Flow Steering (aRFS)
----------------------------------------
Devices based on the Intel(R) Ethernet Controller 800 Series support
Accelerated Receive Flow Steering (aRFS) on the PF. aRFS is a load-balancing
mechanism that allows you to direct packets to the same CPU where an
application is running or consuming the packets in that flow.

NOTES:

- aRFS requires that ntuple filtering is enabled via ethtool.
- aRFS support is limited to the following packet types:

    - TCP over IPv4 and IPv6
    - UDP over IPv4 and IPv6
    - Nonfragmented packets

- aRFS only supports Flow Director filters, which consist of the
  source/destination IP addresses and source/destination ports.
- aRFS and ethtool's ntuple interface both use the device's Flow Director. aRFS
  and ntuple features can coexist, but you may encounter unexpected results if
  there's a conflict between aRFS and ntuple requests. See "Intel(R) Ethernet
  Flow Director" for additional information.

To set up aRFS:

1. Enable the Intel Ethernet Flow Director and ntuple filters using ethtool.

::

   # ethtool -K <ethX> ntuple on

2. Set up the number of entries in the global flow table. For example:

::

   # NUM_RPS_ENTRIES=16384
   # echo $NUM_RPS_ENTRIES > /proc/sys/net/core/rps_sock_flow_entries

3. Set up the number of entries in the per-queue flow table. For example:

::

   # NUM_RX_QUEUES=64
   # for file in /sys/class/net/$IFACE/queues/rx-*/rps_flow_cnt; do
   # echo $(($NUM_RPS_ENTRIES/$NUM_RX_QUEUES)) > $file;
   # done

4. Disable the IRQ balance daemon (this is only a temporary stop of the service
   until the next reboot).

::

   # systemctl stop irqbalance

5. Configure the interrupt affinity.

   See ``/Documentation/core-api/irq/irq-affinity.rst``


To disable aRFS using ethtool::

  # ethtool -K <ethX> ntuple off

NOTE: This command will disable ntuple filters and clear any aRFS filters in
software and hardware.

Example Use Case:

1. Set the server application on the desired CPU (e.g., CPU 4).

::

   # taskset -c 4 netserver

2. Use netperf to route traffic from the client to CPU 4 on the server with
   aRFS configured. This example uses TCP over IPv4.

::

   # netperf -H <Host IPv4 Address> -t TCP_STREAM

VF 생성, 통계, VLAN, link와 MAC

508-589

Virtual Function(VF) 활성화

sysfs로 VF를 만들거나 제거합니다.

echo 4 > /sys/class/net/<ethX>/device/sriov_numvfs
echo 0 > /sys/class/net/<ethX>/device/sriov_numvfs
cat /sys/class/net/<ethX>/device/sriov_totalvfs

ice driver의 VF 상한은 모든 port를 합해 256개입니다. PF별 지원 수는 `sriov_totalvfs`로 확인합니다. SR-IOV와 link aggregation(LAG)/bonding은 상호 배타적이며 driver가 이를 검사합니다.

PF에서 VF statistic 표시

ip -s link show dev <ethX>

PF driver는 PF와 구성된 모든 VF의 statistic 일부를 표시합니다. 가능한 VF마다 block을 출력하므로 결과가 매우 클 수 있고, 구성하지 않은 VF는 0을 표시합니다.

SR-IOV adapter port의 VLAN tagging 구성

VF driver를 load하거나 VM을 boot하기 전에 VLAN을 구성해야 합니다. transmit 때 tag를 삽입하고 receive frame에서 제거하는 port VLAN mode를 VF는 인식하지 못합니다.

ip link set dev <ethX> vf <id> vlan <vlan id>
ip link set dev eth0 vf 0 vlan 10

physical port가 disconnected일 때 VF link 활성화

PF link가 down이어도 host PF에서 연결된 VF의 link를 강제로 up할 수 있습니다. system이 지원하지 않으면 command가 동작하지 않을 수 있습니다.

ip link set eth0 vf 0 state enable

VF MAC address 설정

ip link set <ethX> vf 0 mac <address>
ip link set <ethX> vf 0 mac 00:01:02:03:04:05

설정은 PF를 reload할 때까지 유지됩니다. host에서 VF MAC을 할당하면 이후 VM 안에서 보내는 MAC 변경 request가 차단됩니다. 이는 security feature이며 VM은 제한을 모르므로 변경을 시도하면 MDD event가 발생합니다.

Enabling Virtual Functions (VFs)
--------------------------------
Use sysfs to enable virtual functions (VF).

For example, you can create 4 VFs as follows::

  # echo 4 > /sys/class/net/<ethX>/device/sriov_numvfs

To disable VFs, write 0 to the same file::

  # echo 0 > /sys/class/net/<ethX>/device/sriov_numvfs

The maximum number of VFs for the ice driver is 256 total (all ports). To check
how many VFs each PF supports, use the following command::

  # cat /sys/class/net/<ethX>/device/sriov_totalvfs

Note: You cannot use SR-IOV when link aggregation (LAG)/bonding is active, and
vice versa. To enforce this, the driver checks for this mutual exclusion.


Displaying VF Statistics on the PF
----------------------------------
Use the following command to display the statistics for the PF and its VFs::

  # ip -s link show dev <ethX>

NOTE: The output of this command can be very large due to the maximum number of
possible VFs.

The PF driver will display a subset of the statistics for the PF and for all
VFs that are configured. The PF will always print a statistics block for each
of the possible VFs, and it will show zero for all unconfigured VFs.


Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports
--------------------------------------------------------
To configure VLAN tagging for the ports on an SR-IOV enabled adapter, use the
following command. The VLAN configuration should be done before the VF driver
is loaded or the VM is booted. The VF is not aware of the VLAN tag being
inserted on transmit and removed on received frames (sometimes called "port
VLAN" mode).

::

  # ip link set dev <ethX> vf <id> vlan <vlan id>

For example, the following will configure PF eth0 and the first VF on VLAN 10::

  # ip link set dev eth0 vf 0 vlan 10


Enabling a VF link if the port is disconnected
----------------------------------------------
If the physical function (PF) link is down, you can force link up (from the
host PF) on any virtual functions (VF) bound to the PF.

For example, to force link up on VF 0 bound to PF eth0::

  # ip link set eth0 vf 0 state enable

Note: If the command does not work, it may not be supported by your system.


Setting the MAC Address for a VF
--------------------------------
To change the MAC address for the specified VF::

  # ip link set <ethX> vf 0 mac <address>

For example::

  # ip link set <ethX> vf 0 mac 00:01:02:03:04:05

This setting lasts until the PF is reloaded.

NOTE: Assigning a MAC address for a VF from the host will disable any
subsequent requests to change the MAC address from within the VM. This is a
security feature. The VM is not aware of this restriction, so if this is
attempted in the VM, it will trigger MDD events.

Trusted VF, MDD와 anti-spoofing

590-672

Trusted VF와 VF promiscuous mode

특정 VF를 trusted로 지정하면 해당 VF가 PF에 selective promiscuous mode를 요청할 수 있습니다.

ip link set dev <ethX> vf 1 trust [on|off]

promiscuous mode를 요청하기 전에 VF를 trusted로 설정해야 합니다. trusted가 아니면 PF가 request를 무시합니다. VF driver load 후 trusted로 바꿨다면 promiscuous request를 다시 보내야 합니다.

ip link set <ethX> promisc on
ip link set <ethX> allmulticast on
ethtool --set-priv-flags <ethX> vf-true-promisc-support on

`vf-true-promisc-support` default는 off이므로 VF promiscuous mode가 limited입니다. flag를 on으로 설정하면 VF가 모든 ingress traffic을 보는 true promiscuous를 선택합니다. flag 자체는 mode를 켜지 않고 ip link로 켰을 때 limited와 true 중 어느 유형을 쓸지 정합니다.

이 flag는 device 전체에 영향을 주는 global 설정이지만 첫 PF에만 노출됩니다. 문서에 명시된 대로 PF는 flag와 관계없이 limited promiscuous mode를 유지합니다.

`ip link add link eth2 name eth2.100 type vlan id 100`으로 VF VLAN interface를 추가하면 VLAN 100 traffic을 받습니다. promiscuous 설정과 VLAN interface 추가 순서는 상관없습니다.

VF용 Malicious Driver Detection(MDD)

일부 Intel device는 VF의 malicious traffic을 감지해 VF driver reset 전까지 Tx/Rx queue를 disable하거나 문제 packet을 drop합니다. PF system log의 MDD message는 dmesg로 확인합니다.

  • VF에서 MDD event가 기록되면 올바른 VF driver가 설치되었는지 확인합니다.
  • VF 또는 VM을 수동 reload하거나 automatic VF reset을 켜 기능을 복원합니다.
  • automatic reset이 켜져 있으면 PF가 receive-path MDD event를 감지하자마자 VF를 reset하고 queue를 다시 활성화합니다.
  • 꺼져 있으면 PF가 자동 reset하지 않습니다.
ethtool --set-priv-flags <ethX> mdd-auto-reset-vf on|off

VF용 MAC 및 VLAN anti-spoofing

VF interface의 malicious driver가 spoofed packet을 보내려 하면 hardware가 drop하고 transmit하지 않습니다. 특정 VF에서는 다음과 같이 비활성화할 수 있습니다.

ip link set <ethX> vf <vf id> spoofchk {off|on}
Trusted VFs and VF Promiscuous Mode
-----------------------------------
This feature allows you to designate a particular VF as trusted and allows that
trusted VF to request selective promiscuous mode on the Physical Function (PF).

To set a VF as trusted or untrusted, enter the following command in the
Hypervisor::

  # ip link set dev <ethX> vf 1 trust [on|off]

NOTE: It's important to set the VF to trusted before setting promiscuous mode.
If the VM is not trusted, the PF will ignore promiscuous mode requests from the
VF. If the VM becomes trusted after the VF driver is loaded, you must make a
new request to set the VF to promiscuous.

Once the VF is designated as trusted, use the following commands in the VM to
set the VF to promiscuous mode.

For promiscuous all::

  # ip link set <ethX> promisc on
  Where <ethX> is a VF interface in the VM

For promiscuous Multicast::

  # ip link set <ethX> allmulticast on
  Where <ethX> is a VF interface in the VM

NOTE: By default, the ethtool private flag vf-true-promisc-support is set to
"off," meaning that promiscuous mode for the VF will be limited. To set the
promiscuous mode for the VF to true promiscuous and allow the VF to see all
ingress traffic, use the following command::

  # ethtool --set-priv-flags <ethX> vf-true-promisc-support on

The vf-true-promisc-support private flag does not enable promiscuous mode;
rather, it designates which type of promiscuous mode (limited or true) you will
get when you enable promiscuous mode using the ip link commands above. Note
that this is a global setting that affects the entire device. However, the
vf-true-promisc-support private flag is only exposed to the first PF of the
device. The PF remains in limited promiscuous mode regardless of the
vf-true-promisc-support setting.

Next, add a VLAN interface on the VF interface. For example::

  # ip link add link eth2 name eth2.100 type vlan id 100

Note that the order in which you set the VF to promiscuous mode and add the
VLAN interface does not matter (you can do either first). The result in this
example is that the VF will get all traffic that is tagged with VLAN 100.


Malicious Driver Detection (MDD) for VFs
----------------------------------------
Some Intel Ethernet devices use Malicious Driver Detection (MDD) to detect
malicious traffic from the VF and disable Tx/Rx queues or drop the offending
packet until a VF driver reset occurs. You can view MDD messages in the PF's
system log using the dmesg command.

- If the PF driver logs MDD events from the VF, confirm that the correct VF
  driver is installed.
- To restore functionality, you can manually reload the VF or VM or enable
  automatic VF resets.
- When automatic VF resets are enabled, the PF driver will immediately reset
  the VF and reenable queues when it detects MDD events on the receive path.
- If automatic VF resets are disabled, the PF will not automatically reset the
  VF when it detects MDD events.

To enable or disable automatic VF resets, use the following command::

  # ethtool --set-priv-flags <ethX> mdd-auto-reset-vf on|off


MAC and VLAN Anti-Spoofing Feature for VFs
------------------------------------------
When a malicious driver on a Virtual Function (VF) interface attempts to send a
spoofed packet, it is dropped by the hardware and not transmitted.

NOTE: This feature can be disabled for a specific VF::

  # ip link set <ethX> vf <vf id> spoofchk {off|on}

Jumbo frame과 speed·duplex

673-735

Jumbo Frame

MTU를 default 1500보다 크게 설정하면 jumbo frame이 활성화됩니다.

ifconfig <ethX> mtu 9000 up
ip link set mtu 9000 dev <ethX>
ip link set up dev <ethX>

설정은 reboot 후 유지되지 않습니다. 최대 MTU는 9702이고 최대 jumbo frame 크기는 9728 bytes입니다.

driver는 jumbo packet 하나를 받기 위해 page-size buffer 여러 개를 사용해 receive allocation의 buffer starvation을 줄입니다. jumbo frame에서 packet loss는 throughput에 더 큰 영향을 줄 수 있으므로 성능이 떨어지면 flow control을 켜는 것이 도움이 될 수 있습니다.

Speed와 duplex 구성

문제를 다룰 때 copper adapter와 fiber adapter를 구분해야 합니다. copper connection은 default로 link partner와 auto-negotiation해 최적 설정을 찾습니다.

auto-negotiation으로 link가 되지 않으면 adapter와 partner를 동일한 값으로 수동 구성해야 할 수 있습니다. 주로 auto-negotiation을 지원하지 않거나 특정 speed/duplex로 고정된 구형 switch에 연결할 때만 필요합니다.

1 Gbps 이상은 강제로 고정할 수 없으며 autonegotiation advertising으로 수동 설정합니다. speed, duplex와 advertising은 ethtool로 구성하고 지원 값은 `ethtool <ethX>`로 확인합니다.

주의: 숙련된 network administrator만 speed/duplex를 강제하거나 advertising을 수동 변경해야 합니다. switch와 adapter 설정은 항상 일치해야 하며 다르면 성능이 낮아지거나 adapter가 동작하지 않을 수 있습니다.

Jumbo Frames
------------
Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU)
to a value larger than the default value of 1500.

Use the ifconfig command to increase the MTU size. For example, enter the
following where <ethX> is the interface number::

  # ifconfig <ethX> mtu 9000 up

Alternatively, you can use the ip command as follows::

  # ip link set mtu 9000 dev <ethX>
  # ip link set up dev <ethX>

This setting is not saved across reboots.


NOTE: The maximum MTU setting for jumbo frames is 9702. This corresponds to the
maximum jumbo frame size of 9728 bytes.

NOTE: This driver will attempt to use multiple page sized buffers to receive
each jumbo packet. This should help to avoid buffer starvation issues when
allocating receive packets.

NOTE: Packet loss may have a greater impact on throughput when you use jumbo
frames. If you observe a drop in performance after enabling jumbo frames,
enabling flow control may mitigate the issue.


Speed and Duplex Configuration
------------------------------
In addressing speed and duplex configuration issues, you need to distinguish
between copper-based adapters and fiber-based adapters.

In the default mode, an Intel(R) Ethernet Network Adapter using copper
connections will attempt to auto-negotiate with its link partner to determine
the best setting. If the adapter cannot establish link with the link partner
using auto-negotiation, you may need to manually configure the adapter and link
partner to identical settings to establish link and pass packets. This should
only be needed when attempting to link with an older switch that does not
support auto-negotiation or one that has been forced to a specific speed or
duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds
and higher cannot be forced. Use the autonegotiation advertising setting to
manually set devices for 1 Gbps and higher.

Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility. For the latest version, download and install ethtool from the
following website:

   https://kernel.org/pub/software/network/ethtool/

To see the speed configurations your device supports, run the following::

  # ethtool <ethX>

Caution: Only experienced network administrators should force speed and duplex
or change autonegotiation advertising manually. The settings at the switch must
always match the adapter settings. Adapter performance may suffer or your
adapter may not operate if you configure the adapter differently from your
switch.

DCB와 firmware LLDP agent

736-805

Data Center Bridging(DCB)

kernel은 TC0가 있다고 가정하며 TC0가 없으면 device의 Priority Flow Control(PFC)을 비활성화합니다. switch에서 DCB를 구성할 때 TC0를 활성화하십시오.

DCB는 hardware QoS configuration입니다. 802.1p VLAN priority tag로 traffic을 8개 priority로 분류하고, 802.1Qbb PFC로 stress 중 packet drop을 제한하며, 802.1Qaz로 각 priority의 bandwidth를 hardware에서 enforce합니다.

DCB는 보통 LLDP(802.1AB)의 specialization인 DCBX(802.1Qaz)로 구성합니다. ice driver는 상호 배타적인 두 DCBX variant를 지원합니다.

  • Firmware-based LLDP Agent
  • Software-based LLDP Agent

firmware mode에서는 firmware가 모든 LLDP traffic을 가로채 DCBX negotiation을 처리합니다. adapter는 `willing` mode로 link partner의 DCB 설정을 받고 local user는 negotiated configuration만 조회할 수 있습니다.

software mode에서는 LLDP traffic이 network stack과 user space로 전달되어 software agent가 처리합니다. adapter는 willing 또는 nonwilling mode로 동작하고 local에서 DCB를 조회·설정할 수 있습니다. 이 mode를 사용하려면 firmware LLDP agent를 꺼야 합니다.

  • firmware LLDP agent는 ethtool private flag로 켜고 끕니다.
  • software DCBX는 Linux DCB Netlink API와 연동하는 agent를 사용하며 OpenLLDP를 권장합니다.
  • driver는 user space가 port DCB configuration을 질의하도록 DCB netlink interface layer를 구현합니다.
  • DCB와 iSCSI 조합은 지원하지 않습니다.

FW-LLDP

설정은 port별이며 boot 후에도 유지됩니다. UEFI HII의 `LLDP Agent` attribute가 켜져 있어야 OS에서 설정할 수 있습니다.

ethtool --set-priv-flags <ethX> fw-lldp-agent on
ethtool --set-priv-flags <ethX> fw-lldp-agent off
ethtool --show-priv-flags <ethX>
Data Center Bridging (DCB)
--------------------------
NOTE: The kernel assumes that TC0 is available, and will disable Priority Flow
Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is
enabled when setting up DCB on your switch.

DCB is a configuration Quality of Service implementation in hardware. It uses
the VLAN priority tag (802.1p) to filter traffic. That means that there are 8
different priorities that traffic can be filtered into. It also enables
priority flow control (802.1Qbb) which can limit or eliminate the number of
dropped packets during network stress. Bandwidth can be allocated to each of
these priorities, which is enforced at the hardware level (802.1Qaz).

DCB is normally configured on the network using the DCBX protocol (802.1Qaz), a
specialization of LLDP (802.1AB). The ice driver supports the following
mutually exclusive variants of DCBX support:

1) Firmware-based LLDP Agent
2) Software-based LLDP Agent

In firmware-based mode, firmware intercepts all LLDP traffic and handles DCBX
negotiation transparently for the user. In this mode, the adapter operates in
"willing" DCBX mode, receiving DCB settings from the link partner (typically a
switch). The local user can only query the negotiated DCB configuration. For
information on configuring DCBX parameters on a switch, please consult the
switch manufacturer's documentation.

In software-based mode, LLDP traffic is forwarded to the network stack and user
space, where a software agent can handle it. In this mode, the adapter can
operate in either "willing" or "nonwilling" DCBX mode and DCB configuration can
be both queried and set locally. This mode requires the FW-based LLDP Agent to
be disabled.

NOTE:

- You can enable and disable the firmware-based LLDP Agent using an ethtool
  private flag. Refer to the "FW-LLDP (Firmware Link Layer Discovery Protocol)"
  section in this README for more information.
- In software-based DCBX mode, you can configure DCB parameters using software
  LLDP/DCBX agents that interface with the Linux kernel's DCB Netlink API. We
  recommend using OpenLLDP as the DCBX agent when running in software mode. For
  more information, see the OpenLLDP man pages and
  https://github.com/intel/openlldp.
- The driver implements the DCB netlink interface layer to allow the user space
  to communicate with the driver and query DCB configuration for the port.
- iSCSI with DCB is not supported.


FW-LLDP (Firmware Link Layer Discovery Protocol)
------------------------------------------------
Use ethtool to change FW-LLDP settings. The FW-LLDP setting is per port and
persists across boots.

To enable LLDP::

  # ethtool --set-priv-flags <ethX> fw-lldp-agent on

To disable LLDP::

  # ethtool --set-priv-flags <ethX> fw-lldp-agent off

To check the current LLDP setting::

  # ethtool --show-priv-flags <ethX>

NOTE: You must enable the UEFI HII "LLDP Agent" attribute for this setting to
take effect. If "LLDP AGENT" is set to disabled, you cannot enable it from the
OS.

Flow control, NAPI와 MACVLAN

806-863

Flow Control

Ethernet Flow Control(IEEE 802.3x)은 ice가 pause frame을 송수신하도록 ethtool로 구성합니다. Tx가 켜지면 receive packet buffer가 threshold를 넘을 때 pause frame을 만들고, Rx가 켜지면 pause frame의 delay 동안 transmit unit이 멈춥니다.

flow-control capable link partner가 필요하며 default는 off입니다.

ethtool -A <ethX> rx <on|off> tx <on|off>

auto-negotiation이 꺼져 있을 때는 직접 Flow Control을 켜거나 끕니다. 켜져 있으면 link partner와 negotiation할 parameter를 바꿉니다. device에 따라 auto-negotiation 설정을 바꿀 수 없을 수 있습니다.

  • port와 link partner 양쪽에 flow control이 필요합니다. 한쪽만 꺼져 있으면 heavy traffic에서 port가 정지한 것처럼 보일 수 있습니다.
  • DCB를 끈 뒤 LFC status는 enabled지만 traffic이 pause되지 않을 수 있습니다. `ethtool -A`로 Rx/Tx를 모두 off했다가 다시 on합니다.

NAPI

driver는 NAPI(Rx polling mode)를 지원합니다. 자세한 내용은 `Documentation/networking/napi.rst`를 참고하십시오.

MACVLAN

driver는 MACVLAN을 지원합니다. `lsmod | grep macvlan`으로 load 여부를 확인하거나 `modprobe macvlan`으로 load할 수 있습니다. passthru mode에서는 MACVLAN device 하나만 만들 수 있으며 기반 PF의 MAC address를 상속합니다.

Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for ice. When transmit is enabled,
pause frames are generated when the receive packet buffer crosses a predefined
threshold. When receive is enabled, the transmit unit will halt for the time
delay specified when a pause frame is received.

NOTE: You must have a flow control capable link partner.

Flow Control is disabled by default.

Use ethtool to change the flow control settings.

To enable or disable Rx or Tx Flow Control::

  # ethtool -A <ethX> rx <on|off> tx <on|off>

Note: This command only enables or disables Flow Control if auto-negotiation is
disabled. If auto-negotiation is enabled, this command changes the parameters
used for auto-negotiation with the link partner.

Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending
on your device, you may not be able to change the auto-negotiation setting.

NOTE:

- The ice driver requires flow control on both the port and link partner. If
  flow control is disabled on one of the sides, the port may appear to hang on
  heavy traffic.
- You may encounter issues with link-level flow control (LFC) after disabling
  DCB. The LFC status may show as enabled but traffic is not paused. To resolve
  this issue, disable and reenable LFC using ethtool::

   # ethtool -A <ethX> rx off tx off
   # ethtool -A <ethX> rx on tx on


NAPI
----

This driver supports NAPI (Rx polling mode).

See :ref:`Documentation/networking/napi.rst <napi>` for more information.

MACVLAN
-------
This driver supports MACVLAN. Kernel support for MACVLAN can be tested by
checking if the MACVLAN driver is loaded. You can run 'lsmod | grep macvlan' to
see if the MACVLAN driver is loaded or run 'modprobe macvlan' to try to load
the MACVLAN driver.

NOTE:

- In passthru mode, you can only set up one MACVLAN device. It will inherit the
  MAC address of the underlying PF (Physical Function) device.

IEEE 802.1ad QinQ

864-903

IEEE 802.1ad(QinQ) 지원

QinQ는 Ethernet frame 하나에 여러 VLAN ID를 넣는 tag stack을 허용해 L2 tunneling과 VLAN 내부 traffic 분리에 사용합니다.

  • 802.1ad packet에는 receive checksum offload와 VLAN acceleration을 지원하지 않습니다.
  • `ethtool -K <ethX> rxvlan off`로 VLAN stripping을 끄지 않으면 0x88A8 traffic을 받을 수 없습니다.
  • 같은 port에 0x8100 또는 0x8100/0x8100 VLAN이 구성되어 있으면 0x88A8/0x8100 double VLAN과 함께 사용할 수 없습니다.
  • VF가 0x88A8/0x8100 traffic을 transmit하려면 port VLAN이 없어야 하고 PF에서 spoofchk를 꺼야 합니다.
  • SR-IOV에서 true promiscuous와 double VLAN이 함께 켜지면 VF가 inner VLAN header 기준 traffic을 모두 받지 못할 수 있습니다.

QinQ 구성 예시는 다음과 같습니다.

ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371

`24`와 `371`은 VLAN ID 예시입니다.

IEEE 802.1ad (QinQ) Support
---------------------------
The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN
IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as
"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks
allow L2 tunneling and the ability to segregate traffic within a particular
VLAN ID, among other uses.

NOTES:

- Receive checksum offloads and VLAN acceleration are not supported for 802.1ad
  (QinQ) packets.

- 0x88A8 traffic will not be received unless VLAN stripping is disabled with
  the following command::

    # ethtool -K <ethX> rxvlan off

- 0x88A8/0x8100 double VLANs cannot be used with 0x8100 or 0x8100/0x8100 VLANS
  configured on the same port. 0x88a8/0x8100 traffic will not be received if
  0x8100 VLANs are configured.

- The VF can only transmit 0x88A8/0x8100 (i.e., 802.1ad/802.1Q) traffic if:

    1) The VF is not assigned a port VLAN.
    2) spoofchk is disabled from the PF. If you enable spoofchk, the VF will
       not transmit 0x88A8/0x8100 traffic.

- The VF may not receive all network traffic based on the Inner VLAN header
  when VF true promiscuous mode (vf-true-promisc-support) and double VLANs are
  enabled in SR-IOV mode.

The following are examples of how to configure 802.1ad (QinQ)::

  # ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24
  # ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371

  Where "24" and "371" are example VLAN IDs.

Tunnel·UDP offload, PTP pin과 GNSS

904-954

Tunnel/Overlay Stateless Offload

hardware와 software 구성에 따라 VXLAN, GENEVE 등의 tunnel과 overlay를 지원합니다. stateless offload는 default로 켜져 있으며 `ethtool -k <ethX>`로 상태를 봅니다.

UDP Segmentation Offload

최대 64K payload의 UDP packet transmit segmentation을 adapter가 valid Ethernet frame으로 처리합니다. OS software보다 빠르고 CPU resource도 줄일 수 있습니다. 전송 application이 UDP segmentation offload를 지원해야 합니다.

ethtool -K <ethX> tx-udp-segmentation [off|on]

PTP pin interface

모든 adapter는 표준 PTP pin interface를 지원합니다. SDP(Software Definable Pin)는 periodic output과 external timestamp를 모두 지원하는 single-ended pin입니다. TIME_SYNC와 1PPS 같은 differential I/O pin은 한 기능만 지원합니다.

DPLL이 있는 adapter는 pin이 board가 아니라 DPLL에 연결될 수 있습니다. 이 구성에서는 고정 방향인 SDP만 노출됩니다. PTP input을 보려면 DPLL을 올바르게 구성해야 하고, output을 board SMA/U.FL pin으로 내보내려면 DPLL output pin을 수동 구성해야 합니다.

GNSS module

kernel을 `CONFIG_GNSS=y` 또는 `CONFIG_GNSS=m`으로 compile해야 합니다. physical module이 있으면 `/dev/gnss<id>`가 생성되어 GNSS message를 읽고 지원 command를 쓸 수 있습니다.

driver는 GNSS object의 raw byte를 i2c로 receiver에 쓰므로 write command protocol은 GNSS hardware module에 따라 다릅니다. 구성은 hardware 문서를 참고하십시오.

Tunnel/Overlay Stateless Offloads
---------------------------------
Supported tunnels and overlays include VXLAN, GENEVE, and others depending on
hardware and software configuration. Stateless offloads are enabled by default.

To view the current state of all offloads::

  # ethtool -k <ethX>


UDP Segmentation Offload
------------------------
Allows the adapter to offload transmit segmentation of UDP packets with
payloads up to 64K into valid Ethernet frames. Because the adapter hardware is
able to complete data segmentation much faster than operating system software,
this feature may improve transmission performance.
In addition, the adapter may use fewer CPU resources.

NOTE:

- The application sending UDP packets must support UDP segmentation offload.

To enable/disable UDP Segmentation Offload, issue the following command::

  # ethtool -K <ethX> tx-udp-segmentation [off|on]

PTP pin interface
-----------------
All adapters support standard PTP pin interface. SDPs (Software Definable Pin)
are single ended pins with both periodic output and external timestamp
supported. There are also specific differential input/output pins (TIME_SYNC,
1PPS) with only one of the functions supported.

There are adapters with DPLL, where pins are connected to the DPLL instead of
being exposed on the board. You have to be aware that in those configurations,
only SDP pins are exposed and each pin has its own fixed direction.
To see input signal on those PTP pins, you need to configure DPLL properly.
Output signal is only visible on DPLL and to send it to the board SMA/U.FL pins,
DPLL output pins have to be manually configured.

GNSS module
-----------
Requires kernel compiled with CONFIG_GNSS=y or CONFIG_GNSS=m.
Allows user to read messages from the GNSS hardware module and write supported
commands. If the module is physically present, a GNSS device is spawned:
``/dev/gnss<id>``.
The protocol of write command is dependent on the GNSS hardware module as the
driver writes raw bytes by the GNSS object to the receiver through i2c. Please
refer to the hardware GNSS module documentation for configuration details.

Firmware logging module 구성

955-1022

Firmware(FW) logging

driver는 PF 0에서만 debugfs를 통한 FW logging을 지원합니다. NIC firmware가 기능을 지원하지 않으면 ice debugfs directory에 `fwlog` file이 생성되지 않습니다.

Module 구성

logging은 module별로 구성하며 `all`을 쓰지 않는 한 각 module을 독립적인 값으로 설정할 수 있습니다. module file은 `fwlog/modules` 아래에 만들어집니다.

echo <log_level> > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/<module>

log level은 `none`, `error`, `warning`, `normal`, `verbose`이며 각 level은 이전 lower level의 message를 포함합니다.

지원 module name

  • general, ctrl, link, link_topo, dnl, i2c, sdp, mdio
  • adminq, hdma, lldp, dcbx, dcb, xlr, nvm, auth, vpd, iosf
  • parser, sw, scheduler, txq, rsvd, post, watchdog, task_dispatch
  • mng, synce, health, tsdrv, pfreg, mdlver, all

`all`은 모든 module의 log level을 한꺼번에 설정하거나 모두 읽는 특별한 name입니다.

Firmware (FW) logging
---------------------
The driver supports FW logging via the debugfs interface on PF 0 only. The FW
running on the NIC must support FW logging; if the FW doesn't support FW logging
the 'fwlog' file will not get created in the ice debugfs directory.

Module configuration
~~~~~~~~~~~~~~~~~~~~
Firmware logging is configured on a per module basis. Each module can be set to
a value independent of the other modules (unless the module 'all' is specified).
The modules will be instantiated under the 'fwlog/modules' directory.

The user can set the log level for a module by writing to the module file like
this::

  # echo <log_level> > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/<module>

where

* log_level is a name as described below. Each level includes the
  messages from the previous/lower level

      *        none
      *        error
      *        warning
      *        normal
      *        verbose

* module is a name that represents the module to receive events for. The
  module names are

      *        general
      *        ctrl
      *        link
      *        link_topo
      *        dnl
      *        i2c
      *        sdp
      *        mdio
      *        adminq
      *        hdma
      *        lldp
      *        dcbx
      *        dcb
      *        xlr
      *        nvm
      *        auth
      *        vpd
      *        iosf
      *        parser
      *        sw
      *        scheduler
      *        txq
      *        rsvd
      *        post
      *        watchdog
      *        task_dispatch
      *        mng
      *        synce
      *        health
      *        tsdrv
      *        pfreg
      *        mdlver
      *        all

The name 'all' is special and allows the user to set all of the modules to the
specified log_level or to read the log_level of all of the modules.

FW log 설정 예시, 활성화와 data 회수

1023-1072

module 구성 예시

echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link
echo warning > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/ctrl
echo none > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/dcb
echo normal > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all
cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/general
cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all

FW log 활성화

module을 구성하면 관심 event를 만들도록 firmware에 알리지만 event가 driver로 전송되지는 않습니다. `fwlog/enable`에 1을 쓰면 활성화하고 0을 쓰면 비활성화합니다.

echo 1 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/enable

FW log data 회수

`fwlog/data`를 읽어 binary log를 회수합니다. Intel에 전달해 user issue debug에 사용합니다. data를 지우려면 logging을 끈 상태에서 아무 값이나 씁니다.

cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data > fwlog.bin
echo 0 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data
Example usage to configure the modules
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

To set a single module to 'verbose'::

  # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link

To set multiple modules then issue the command multiple times::

  # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link
  # echo warning > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/ctrl
  # echo none > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/dcb

To set all the modules to the same value::

  # echo normal > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all

To read the log_level of a specific module (e.g. module 'general')::

  # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/general

To read the log_level of all the modules::

  # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all

Enabling FW log
~~~~~~~~~~~~~~~
Configuring the modules indicates to the FW that the configured modules should
generate events that the driver is interested in, but it **does not** send the
events to the driver until the enable message is sent to the FW. To do this
the user can write a 1 (enable) or 0 (disable) to 'fwlog/enable'. An example
is::

  # echo 1 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/enable

Retrieving FW log data
~~~~~~~~~~~~~~~~~~~~~~
The FW log data can be retrieved by reading from 'fwlog/data'. The user can
write any value to 'fwlog/data' to clear the data. The data can only be cleared
when FW logging is disabled. The FW log data is a binary file that is sent to
Intel and used to help debug user issues.

An example to read the data is::

  # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data > fwlog.bin

An example to clear the data is::

  # echo 0 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data

FW log 전송 빈도와 buffer 크기

1073-1095

log event를 driver로 보내는 빈도 변경

driver는 Admin Receive Queue(ARQ)에서 FW log data를 받습니다. `fwlog/nr_messages`는 1-128 범위이며 1은 message마다 push, 128은 최대 AQ command buffer가 찼을 때만 push를 뜻합니다. 권장 값은 10이고 file을 읽어 현재 값을 확인합니다.

echo 50 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/nr_messages

FW log data용 memory 크기 구성

default driver buffer는 1MB입니다. `fwlog/log_size`에 `128K`, `256K`, `512K`, `1M`, `2M` 중 하나를 써서 변경합니다. 변경할 때 FW logging은 꺼져 있어야 합니다.

echo 128K > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/log_size
Changing how often the log events are sent to the driver
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver receives FW log data from the Admin Receive Queue (ARQ). The
frequency that the FW sends the ARQ events can be configured by writing to
'fwlog/nr_messages'. The range is 1-128 (1 means push every log message, 128
means push only when the max AQ command buffer is full). The suggested value is
10. The user can see what the value is configured to by reading
'fwlog/nr_messages'. An example to set the value is::

  # echo 50 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/nr_messages

Configuring the amount of memory used to store FW log data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The driver stores FW log data within the driver. The default size of the memory
used to store the data is 1MB. Some use cases may require more or less data so
the user can change the amount of memory that is allocated for FW log data.
To change the amount of memory then write to 'fwlog/log_size'. The value must be
one of: 128K, 256K, 512K, 1M, or 2M. FW logging must be disabled to change the
value. An example of changing the value is::

  # echo 128K > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/log_size

Performance 최적화와 Rx ring

1096-1122

Performance 최적화

driver default는 다양한 workload에 맞춰져 있습니다. 추가 최적화가 필요하면 아래 설정을 시험하십시오.

Rx Descriptor Ring 크기

Rx packet discard를 줄이려면 ethtool로 각 Rx ring의 descriptor 수를 늘립니다.

ethtool -S <ethX> | grep "rx_dropped"
ethtool -G <ethX> rx <N>

`rx_dropped.nic`은 PCIe bandwidth 부족을 뜻할 수도 있습니다. queue drop이 보이면 `<N>` ring entry를 늘려 CPU가 descriptor를 처리하는 동안 발생하는 latency를 임시 buffering할 수 있습니다.

Performance Optimization
========================
Driver defaults are meant to fit a wide variety of workloads, but if further
optimization is required, we recommend experimenting with the following
settings.


Rx Descriptor Ring Size
-----------------------
To reduce the number of Rx packet discards, increase the number of Rx
descriptors for each Rx ring using ethtool.

  Check if the interface is dropping Rx packets due to buffers being full
  (rx_dropped.nic can mean that there is no PCIe bandwidth)::

    # ethtool -S <ethX> | grep "rx_dropped"

  If the previous command shows drops on queues, it may help to increase
  the number of descriptors using 'ethtool -G'::

    # ethtool -G <ethX> rx <N>
    Where <N> is the desired number of ring entries/descriptors

  This can provide temporary buffering for issues that create latency while
  the CPUs process descriptors.

Interrupt rate 제한

1123-1188

Interrupt Rate Limiting

driver는 일반 workload에 맞춘 adaptive Interrupt Throttle Rate(ITR)를 지원합니다. ethtool로 interrupt 사이 microsecond를 조정해 workload별로 customize할 수 있습니다.

수동 설정 전 adaptive mode를 끕니다.

ethtool -C <ethX> adaptive-rx off adaptive-tx off

CPU 사용량을 낮추려면 adaptive ITR을 끄고 Rx/Tx interrupt 빈도를 낮춥니다. `rx-usecs=80`, `tx-usecs=80`은 queue마다 약 12,500 interrupts/s로 제한합니다.

ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80 tx-usecs 80

latency를 줄이려면 두 값을 0으로 설정해 adaptive ITR과 ITR을 모두 끕니다.

ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0

queue별 설정도 가능합니다. `queue_mask 0xa`는 queue 1과 3을 선택하며 static Rx ITR 10 microseconds는 약 100,000 interrupts/s입니다.

ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off rx-usecs 10
ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce

`rx-usecs-high` 범위는 0-236이고 0은 제한 없음입니다. 4,237-250,000 interrupts/s 범위를 제공하며 `rx-usecs`, `tx-usecs`, adaptive moderation과 독립적입니다. hardware granularity가 4 microseconds라 인접 값이 같은 rate가 될 수 있습니다.

다음 예시는 completion indication을 최대 5 microseconds로 두되 `rx-usecs-high=20`으로 총 interrupt를 초당 50,000회로 제한합니다.

ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs-high 20
rx-usecs 5 tx-usecs 5
Interrupt Rate Limiting
-----------------------
This driver supports an adaptive interrupt throttle rate (ITR) mechanism that
is tuned for general workloads. The user can customize the interrupt rate
control for specific workloads, via ethtool, adjusting the number of
microseconds between interrupts.

To set the interrupt rate manually, you must disable adaptive mode::

  # ethtool -C <ethX> adaptive-rx off adaptive-tx off

For lower CPU utilization:

  Disable adaptive ITR and lower Rx and Tx interrupts. The examples below
  affect every queue of the specified interface.

  Setting rx-usecs and tx-usecs to 80 will limit interrupts to about
  12,500 interrupts per second per queue::

    # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80 tx-usecs 80

For reduced latency:

  Disable adaptive ITR and ITR by setting rx-usecs and tx-usecs to 0
  using ethtool::

    # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0

Per-queue interrupt rate settings:

  The following examples are for queues 1 and 3, but you can adjust other
  queues.

  To disable Rx adaptive ITR and set static Rx ITR to 10 microseconds or
  about 100,000 interrupts/second, for queues 1 and 3::

    # ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off
    rx-usecs 10

  To show the current coalesce settings for queues 1 and 3::

    # ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce

Bounding interrupt rates using rx-usecs-high:

  :Valid Range: 0-236 (0=no limit)

   The range of 0-236 microseconds provides an effective range of 4,237 to
   250,000 interrupts per second. The value of rx-usecs-high can be set
   independently of rx-usecs and tx-usecs in the same ethtool command, and is
   also independent of the adaptive interrupt moderation algorithm. The
   underlying hardware supports granularity in 4-microsecond intervals, so
   adjacent values may result in the same interrupt rate.

  The following command would disable adaptive interrupt moderation, and allow
  a maximum of 5 microseconds before indicating a receive or transmit was
  complete. However, instead of resulting in as many as 200,000 interrupts per
  second, it limits total interrupts per second to 50,000 via the rx-usecs-high
  parameter.

  ::

    # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs-high 20
    rx-usecs 5 tx-usecs 5

Virtualized environment, 지원과 trademark

1189-1219

Virtualized environment

VM에서는 vcpupin 같은 mechanism으로 CPU를 개별 lCPU에 고정하고 device의 `/sys/class/net/<ethX>/device/local_cpulist`에 포함된 CPU set을 사용합니다.

VM에서 가능한 만큼 Rx/Tx queue를 구성합니다. 지원 queue 수는 iavf 문서를 참고하십시오.

ethtool -L <virt_interface> rx <max> tx <max>

지원

일반 정보는 `https://www.intel.com/support/`를 참고하십시오. 지원되는 adapter와 kernel에서 공개 source code 문제가 확인되면 구체적인 정보를 `intel-wired-lan@lists.osuosl.org`로 보내십시오.

Trademark

Intel은 미국 및 기타 국가에서 Intel Corporation 또는 그 자회사의 trademark 또는 registered trademark입니다.

그 밖의 name과 brand는 각 소유자의 property일 수 있습니다.

Virtualized Environments
------------------------
In addition to the other suggestions in this section, the following may be
helpful to optimize performance in VMs.

  Using the appropriate mechanism (vcpupin) in the VM, pin the CPUs to
  individual LCPUs, making sure to use a set of CPUs included in the
  device's local_cpulist: ``/sys/class/net/<ethX>/device/local_cpulist``.

  Configure as many Rx/Tx queues in the VM as available. (See the iavf driver
  documentation for the number of queues supported.) For example::

    # ethtool -L <virt_interface> rx <max> tx <max>


Support
=======
For general information, go to the Intel support website at:
https://www.intel.com/support/

If an issue is identified with the released source code on a supported kernel
with a supported adapter, email the specific information related to the issue
to intel-wired-lan@lists.osuosl.org.


Trademarks
==========
Intel is a trademark or registered trademark of Intel Corporation or its
subsidiaries in the United States and/or other countries.

* Other names and brands may be claimed as the property of others.