요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. 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
===============
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.
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
------------------------------
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).
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.
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 (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
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 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 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.
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
------------
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) 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/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 (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.
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
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 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 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 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.
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-86receive 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-220Dynamic 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-345Intel(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-425Flex Byte Flow Director Filter
driver는 packet payload 안의 user-defined data도 matching할 수 있습니다. ethtool `user-def`의 상위 16 bit는 payload offset, 하위 16 bit는 2-byte 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-507Accelerated 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-589Virtual 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-672Trusted 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-735Jumbo 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-805Data 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-863Flow 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-903IEEE 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-954Tunnel/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-1022Firmware(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-1072module 구성 예시
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-1095log 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-1122Performance 최적화
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-1188Interrupt 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-1219Virtualized 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.
요약·해설
ice.rst:1-1219ice는 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와 data-path 제약입니다.
PCIe·DMA latency로 인한 drop을 줄이는 순서입니다.
ethtool reset 종류별 재초기화 범위입니다.
default와 device-specific package 선택 및 Safe Mode 진입입니다.
filter를 안전하게 program하기 위한 공통 제약입니다.
application CPU affinity까지 이어지는 receive steering입니다.
VF 생성과 host policy의 핵심 상한입니다.
trust, promiscuous와 MDD 대응 관계입니다.
frame 크기 및 negotiation 주의사항입니다.
firmware와 software LLDP agent 차이입니다.
0x88A8/0x8100 double VLAN 운용 조건입니다.
overlay, segmentation, PTP·GNSS 기능입니다.
PF0 debugfs logging의 주요 knob입니다.
ring과 interrupt 설정의 대표 trade-off입니다.
vCPU, NUMA locality와 queue 수를 맞춥니다.