요약·해설과 원문, 전문 번역을 서로 분리했습니다. 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 700 Series
=================================================================
Intel 40 Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Overview
- Identifying Your Adapter
- Intel(R) Ethernet Flow Director
- Additional Configurations
- Known Issues
- Support
Driver information can be obtained using ethtool, lspci, and ifconfig.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* Intel(R) Ethernet Controller X710
* Intel(R) Ethernet Controller XL710
* Intel(R) Ethernet Network Connection X722
* Intel(R) Ethernet Controller XXV710
For the best performance, make sure the latest NVM/FW is installed on your
device.
For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support
SFP+ and QSFP+ Devices
----------------------
For information about supported media, refer to this document:
https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf
NOTE: Some adapters based on the Intel(R) Ethernet Controller 700 Series only
support Intel Ethernet Optics modules. On these adapters, other modules are not
supported and will not function. In all cases Intel recommends using Intel
Ethernet Optics; other modules may function but are not validated by Intel.
Contact Intel for supported media types.
NOTE: For connections based on Intel(R) Ethernet Controller 700 Series, support
is dependent on your system board. Please see your vendor for details.
NOTE: In systems that do not have adequate airflow to cool the adapter and
optical modules, you must use high temperature optical modules.
Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs. For example::
#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs #enable VFs
#echo 0 > /sys/class/net/$dev/device/sriov_numvfs #disable VFs
For example, the following instructions will configure PF eth0 and the first VF
on VLAN 10::
$ ip link set dev eth0 vf 0 vlan 10
VLAN Tag Packet Steering
------------------------
Allows you to send all packets with a specific VLAN tag to a particular SR-IOV
virtual function (VF). Further, 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 eth0 vf 1 trust [on|off]
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 eth2 promisc on
Where eth2 is a VF interface in the VM
For promiscuous Multicast:
#ip link set eth2 allmulticast on
Where eth2 is a VF interface in the VM
NOTE: By default, the ethtool priv-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 p261p1 vf-true-promisc-support on
The vf-true-promisc-support priv-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 priv-flag is only exposed to the first PF of the
device. The PF remains in limited promiscuous mode (unless it is in MFP mode)
regardless of the vf-true-promisc-support setting.
Now add a VLAN interface on the VF interface::
#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 end result in
this example is that the VF will get all traffic that is tagged with VLAN 100.
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.
- Supports multiple parameters for flexible flow classification and load
balancing (in SFP mode only).
NOTE: The Linux i40e driver supports the following flow types: IPv4, TCPv4, and
UDPv4. For a given flow type, it supports valid combinations of IP addresses
(source or destination) and UDP/TCP ports (source and destination). For
example, 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: The Linux i40e 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).
To enable or disable the Intel Ethernet Flow Director::
# ethtool -K ethX ntuple <on|off>
When disabling 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 add a filter that directs packet to queue 2, use -U or -N switch::
# ethtool -N 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 -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 action 2 [loc 1]
To see the list of filters currently present::
# ethtool <-u|-n> ethX
Application Targeted Routing (ATR) Perfect Filters
--------------------------------------------------
ATR is enabled by default when the kernel is in multiple transmit queue mode.
An ATR Intel Ethernet Flow Director filter rule is added when a TCP-IP flow
starts and is deleted when the flow ends. When a TCP-IP Intel Ethernet Flow
Director rule is added from ethtool (Sideband filter), ATR is turned off by the
driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
option. For example::
ethtool -K [adapter] ntuple [off|on]
If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
automatically re-enabled.
Packets that match the ATR rules are counted in fdir_atr_match stats in
ethtool, which also can be used to verify whether ATR rules still exist.
Sideband Perfect Filters
------------------------
Sideband Perfect Filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To add a
new filter use the following command::
ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \
dst-port <port> action <queue>
Where:
<device> - the ethernet device to program
<type> - can be ip4, tcp4, udp4, or sctp4
<ip> - the ip address to match on
<port> - the port number to match on
<queue> - the queue to direct traffic towards (-1 discards matching traffic)
Use the following command to display all of the active filters::
ethtool -u <device>
Use the following command to delete a filter::
ethtool -U <device> 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.
The following example matches TCP traffic sent from 192.168.0.1, port 5300,
directed to 192.168.0.5, port 80, and sends 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
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.
Matching on a sub-portion of a field is not supported by the i40e driver, thus
partial mask fields are not supported.
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:
+----------------------------+--------------------------+
| 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.
To create filters that direct traffic to a specific Virtual Function, use the
"action" parameter. Specify the action as a 64 bit value, where the lower 32
bits represents the queue number, while the next 8 bits represent which VF.
Note that 0 is the PF, so the VF identifier is offset by 1. For example::
... action 0x800000002 ...
specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of
that VF.
Note that these filters will not break internal routing rules, and will not
route traffic that otherwise would not have been sent to the specified Virtual
Function.
Setting the link-down-on-close Private Flag
-------------------------------------------
When the link-down-on-close private flag is set to "on", the port's link will
go down when the interface is brought down using the ifconfig ethX down command.
Use ethtool to view and set link-down-on-close, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX link-down-on-close [on|off]
Setting the mdd-auto-reset-vf Private Flag
------------------------------------------
When the mdd-auto-reset-vf private flag is set to "on", the problematic VF will
be automatically reset if a malformed descriptor is detected. If the flag is
set to "off", the problematic VF will be disabled.
Use ethtool to view and set mdd-auto-reset-vf, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX mdd-auto-reset-vf [on|off]
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.
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 <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file::
/etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL
/etc/sysconfig/network/<config_file> // for SLES
NOTE: The maximum MTU setting for Jumbo Frames is 9702. This value coincides
with the maximum Jumbo Frames 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.
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://www.kernel.org/pub/software/network/ethtool/
Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
Retrieves the receive network flow classification configurations.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
Retrieves the hash options for the specified network traffic type.
-N --config-nfc
Configures the receive network flow classification.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r...
Configures the hash options for the specified network traffic type.
udp4 UDP over IPv4
udp6 UDP over IPv6
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.
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.
NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet
Network Adapter XXV710 based devices.
Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility.
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.
An Intel(R) Ethernet Network Adapter using fiber-based connections, however,
will not attempt to auto-negotiate with its link partner since those adapters
operate only in full duplex and only at their native speed.
NAPI
----
NAPI (Rx polling mode) is supported in the i40e driver.
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for i40e. 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 on by default.
Use ethtool to change the flow control settings.
To enable or disable Rx or Tx Flow Control::
ethtool -A eth? 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.
To enable or disable auto-negotiation::
ethtool -s eth? autoneg <on|off>
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.
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 <dev> rx-flow-hash <type> <option>
Where <type> is:
tcp4 signifying TCP over IPv4
udp4 signifying UDP over IPv4
tcp6 signifying TCP over IPv6
udp6 signifying UDP 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.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
NOTE: This feature can be disabled for a specific Virtual Function (VF)::
ip link set <pf dev> vf <vf id> spoofchk {off|on}
IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)
------------------------------------------------------------
Precision Time Protocol (PTP) is used to synchronize clocks in a computer
network. PTP support varies among Intel devices that support this driver. Use
"ethtool -T <netdev name>" to get a definitive list of PTP capabilities
supported by the 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.
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.
NOTES:
Receive checksum offloads, cloud filters, and VLAN acceleration are not
supported for 802.1ad (QinQ) packets.
VXLAN and GENEVE Overlay HW Offloading
--------------------------------------
Virtual Extensible LAN (VXLAN) allows you to extend an L2 network over an L3
network, which may be useful in a virtualized or cloud environment. Some
Intel(R) Ethernet Network devices perform VXLAN processing, offloading it from
the operating system. This reduces CPU utilization.
VXLAN offloading is controlled by the Tx and Rx checksum offload options
provided by ethtool. That is, if Tx checksum offload is enabled, and the
adapter has the capability, VXLAN offloading is also enabled.
Support for VXLAN and GENEVE HW offloading is dependent on kernel support of
the HW offloading features.
Multiple Functions per Port
---------------------------
Some adapters based on the Intel Ethernet Controller X710/XL710 support
multiple functions on a single physical port. Configure these functions through
the System Setup/BIOS.
Minimum TX Bandwidth is the guaranteed minimum data transmission bandwidth, as
a percentage of the full physical port link speed, that the partition will
receive. The bandwidth the partition is awarded will never fall below the level
you specify.
The range for the minimum bandwidth values is:
1 to ((100 minus # of partitions on the physical port) plus 1)
For example, if a physical port has 4 partitions, the range would be:
1 to ((100 - 4) + 1 = 97)
The Maximum Bandwidth percentage represents the maximum transmit bandwidth
allocated to the partition as a percentage of the full physical port link
speed. The accepted range of values is 1-100. The value is used as a limiter,
should you chose that any one particular function not be able to consume 100%
of a port's bandwidth (should it be available). The sum of all the values for
Maximum Bandwidth is not restricted, because no more than 100% of a port's
bandwidth can ever be used.
NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
"add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
64 virtual functions (VFs).
Data Center Bridging (DCB)
--------------------------
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).
Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and
802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only
and can accept settings from a DCBX capable peer. Software configuration of
DCBX parameters via dcbtool/lldptool are not supported.
NOTE: Firmware LLDP can be disabled by setting the private flag disable-fw-lldp.
The i40e driver implements the DCB netlink interface layer to allow user-space
to communicate with the driver and query DCB configuration for the port.
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.
Interrupt Rate Limiting
-----------------------
:Valid Range: 0-235 (0=no limit)
The Intel(R) Ethernet Controller XL710 family supports an interrupt rate
limiting mechanism. The user can control, via ethtool, the number of
microseconds between interrupts.
Syntax::
# ethtool -C ethX rx-usecs-high N
The range of 0-235 microseconds provides an effective range of 4,310 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.
One possible use case is the following::
# ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs \
5 tx-usecs 5
The above 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.
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.
NOTE: For better performance when processing small (64B) frame sizes, try
enabling Hyper threading in the BIOS in order to increase the number of logical
cores in the system and subsequently increase the number of queues available to
the adapter.
Virtualized Environments
------------------------
1. Disable XPS on both ends by using the included virt_perf_default script
or by running the following command as root::
for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;
do echo 0 > $file; done
2. Using the appropriate mechanism (vcpupin) in the vm, pin the cpu's to
individual lcpu's, making sure to use a set of cpu's included in the
device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.
3. Configure as many Rx/Tx queues in the VM as available. Do not rely on
the default setting of 1.
Non-virtualized Environments
----------------------------
Pin the adapter's IRQs to specific cores by disabling the irqbalance service
and using the included set_irq_affinity script. Please see the script's help
text for further options.
- The following settings will distribute the IRQs across all the cores evenly::
# scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]
- The following settings will distribute the IRQs across all the cores that are
local to the adapter (same NUMA node)::
# scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]
For very CPU intensive workloads, we recommend pinning the IRQs to all cores.
For IP Forwarding: Disable Adaptive ITR and lower Rx and Tx interrupts per
queue using ethtool.
- Setting rx-usecs and tx-usecs to 125 will limit interrupts to about 8000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 125 \
tx-usecs 125
For lower CPU utilization: Disable Adaptive ITR and lower Rx and Tx interrupts
per queue using ethtool.
- Setting rx-usecs and tx-usecs to 250 will limit interrupts to about 4000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250 \
tx-usecs 250
For lower latency: Disable Adaptive ITR and ITR by setting Rx and Tx to 0 using
ethtool.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 \
tx-usecs 0
Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.
1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.
Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.
::
# tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
max_rate 1Gbit 3Gbit
map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)
queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)
hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.
shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.
For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]`
2. Enable HW TC offload on interface::
# ethtool -K <interface> hw-tc-offload on
3. Apply TCs to ingress (RX) flow of interface::
# tc qdisc add dev <interface> ingress
NOTES:
- Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.
- ADq is not compatible with cloud filters.
- Setting up channels via ethtool (ethtool -L) is not supported when the
TCs are configured using mqprio.
- You must have iproute2 latest version
- NVM version 6.01 or later is required.
- ADq cannot be enabled when any the following features are enabled: Data
Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband
Filters.
- If another driver (for example, DPDK) has set cloud filters, you cannot
enable ADq.
- Tunnel filters are not supported in ADq. If encapsulated packets do
arrive in non-tunnel mode, filtering will be done on the inner headers.
For example, for VXLAN traffic in non-tunnel mode, PCTYPE is identified
as a VXLAN encapsulated packet, outer headers are ignored. Therefore,
inner headers are matched.
- If a TC filter on a PF matches traffic over a VF (on the PF), that
traffic will be routed to the appropriate queue of the PF, and will
not be passed on the VF. Such traffic will end up getting dropped higher
up in the TCP/IP stack as it does not match PF address data.
- If traffic matches multiple TC filters that point to different TCs,
that traffic will be duplicated and sent to all matching TC queues.
The hardware switch mirrors the packet to a VSI list when multiple
filters are matched.
Known Issues/Troubleshooting
============================
NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do
not support the following features:
* Data Center Bridging (DCB)
* QOS
* VMQ
* SR-IOV
* Task Encapsulation offload (VXLAN, NVGRE)
* Energy Efficient Ethernet (EEE)
* Auto-media detect
Unexpected Issues when the device driver and DPDK share a device
----------------------------------------------------------------
Unexpected issues may result when an i40e device is in multi driver mode and
the kernel driver and DPDK driver are sharing the device. This is because
access to the global NIC resources is not synchronized between multiple
drivers. Any change to the global NIC configuration (writing to a global
register, setting global configuration by AQ, or changing switch modes) will
affect all ports and drivers on the device. Loading DPDK with the
"multi-driver" module parameter may mitigate some of the issues.
TC0 must be enabled when setting up DCB on a switch
---------------------------------------------------
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.
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 [email protected].
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
개요, adapter와 optical media
1-62이 문서는 `GPL-2.0+` 라이선스를 따릅니다.
Intel(R) Ethernet Controller 700 Series용 Linux Base Driver
Intel 40 Gigabit Linux driver
Copyright(c) 1999-2018 Intel Corporation.
목차
- 개요
- Adapter 식별
- Intel(R) Ethernet Flow Director
- 추가 configuration
- 알려진 문제
- 지원
driver 정보는 ethtool, lspci, ifconfig로 확인할 수 있습니다. ethtool update 방법은 뒤의 추가 configuration 절에 있습니다.
hardware requirement는 Intel adapter와 함께 제공된 문서를 참고하십시오. 기재된 모든 hardware requirement는 Linux 사용에도 적용됩니다.
Adapter 식별
드라이버는 다음 controller와 connection 기반 device를 지원합니다.
- Intel(R) Ethernet Controller X710
- Intel(R) Ethernet Controller XL710
- Intel(R) Ethernet Network Connection X722
- Intel(R) Ethernet Controller XXV710
최상의 performance를 위해 최신 NVM/FW를 설치하십시오. adapter 식별, 최신 NVM/FW image와 Intel network driver는 `https://www.intel.com/support`를 참고하십시오.
SFP+ 및 QSFP+ device
지원 media는 `https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf`를 참고하십시오.
일부 700 Series adapter는 Intel Ethernet Optics module만 지원합니다. Intel은 모든 경우 Intel Ethernet Optics 사용을 권장합니다. 다른 module이 동작할 수도 있지만 Intel이 검증하지 않았습니다.
700 Series 기반 connection의 지원 여부는 system board에 따라 달라지므로 vendor에 문의하십시오. adapter와 optical module을 냉각할 airflow가 부족한 system에서는 high-temperature optical module을 사용해야 합니다.
.. SPDX-License-Identifier: GPL-2.0+
=================================================================
Linux Base Driver for the Intel(R) Ethernet Controller 700 Series
=================================================================
Intel 40 Gigabit Linux driver.
Copyright(c) 1999-2018 Intel Corporation.
Contents
========
- Overview
- Identifying Your Adapter
- Intel(R) Ethernet Flow Director
- Additional Configurations
- Known Issues
- Support
Driver information can be obtained using ethtool, lspci, and ifconfig.
Instructions on updating ethtool can be found in the section Additional
Configurations later in this document.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel adapter. All hardware requirements listed apply to use
with Linux.
Identifying Your Adapter
========================
The driver is compatible with devices based on the following:
* Intel(R) Ethernet Controller X710
* Intel(R) Ethernet Controller XL710
* Intel(R) Ethernet Network Connection X722
* Intel(R) Ethernet Controller XXV710
For the best performance, make sure the latest NVM/FW is installed on your
device.
For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
https://www.intel.com/support
SFP+ and QSFP+ Devices
----------------------
For information about supported media, refer to this document:
https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf
NOTE: Some adapters based on the Intel(R) Ethernet Controller 700 Series only
support Intel Ethernet Optics modules. On these adapters, other modules are not
supported and will not function. In all cases Intel recommends using Intel
Ethernet Optics; other modules may function but are not validated by Intel.
Contact Intel for supported media types.
NOTE: For connections based on Intel(R) Ethernet Controller 700 Series, support
is dependent on your system board. Please see your vendor for details.
NOTE: In systems that do not have adequate airflow to cool the adapter and
optical modules, you must use high temperature optical modules.
Virtual Function과 VLAN tag steering
63-122Virtual Function(VF)
sysfs로 VF를 활성화하거나 비활성화합니다.
echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs
echo 0 > /sys/class/net/$dev/device/sriov_numvfs
PF `eth0`의 첫 VF를 VLAN 10으로 구성하는 예시는 다음과 같습니다.
ip link set dev eth0 vf 0 vlan 10
VLAN Tag Packet Steering
특정 VLAN tag가 붙은 packet을 지정한 SR-IOV VF로 모두 보낼 수 있습니다. 특정 VF를 trusted로 지정하면 그 VF가 PF에 selective promiscuous mode를 요청할 수도 있습니다.
Hypervisor에서 VF trust를 설정합니다.
ip link set dev eth0 vf 1 trust [on|off]
trusted VF의 VM에서 promiscuous mode를 설정합니다.
ip link set eth2 promisc on
ip link set eth2 allmulticast on
`eth2`는 VM의 VF interface입니다. 첫 command는 모든 traffic, 둘째 command는 multicast promiscuous mode를 켭니다.
default로 ethtool private flag `vf-true-promisc-support`는 off이므로 VF promiscuous mode가 제한됩니다. 모든 ingress traffic을 볼 수 있는 true promiscuous를 선택하려면 다음처럼 설정합니다.
ethtool --set-priv-flags p261p1 vf-true-promisc-support on
이 flag 자체가 promiscuous mode를 활성화하는 것은 아닙니다. ip link로 mode를 켰을 때 limited와 true 중 어느 유형을 사용할지 정합니다.
device 전체에 영향을 주는 global 설정이지만 첫 PF에만 노출됩니다. PF는 MFP mode가 아니면 flag와 관계없이 limited promiscuous mode를 유지합니다.
VF interface에 VLAN interface를 추가합니다.
ip link add link eth2 name eth2.100 type vlan id 100
promiscuous mode 설정과 VLAN interface 추가 순서는 상관없습니다. 결과적으로 VF는 VLAN 100 tag가 붙은 모든 traffic을 받습니다.
Virtual Functions (VFs)
-----------------------
Use sysfs to enable VFs. For example::
#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs #enable VFs
#echo 0 > /sys/class/net/$dev/device/sriov_numvfs #disable VFs
For example, the following instructions will configure PF eth0 and the first VF
on VLAN 10::
$ ip link set dev eth0 vf 0 vlan 10
VLAN Tag Packet Steering
------------------------
Allows you to send all packets with a specific VLAN tag to a particular SR-IOV
virtual function (VF). Further, 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 eth0 vf 1 trust [on|off]
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 eth2 promisc on
Where eth2 is a VF interface in the VM
For promiscuous Multicast:
#ip link set eth2 allmulticast on
Where eth2 is a VF interface in the VM
NOTE: By default, the ethtool priv-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 p261p1 vf-true-promisc-support on
The vf-true-promisc-support priv-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 priv-flag is only exposed to the first PF of the
device. The PF remains in limited promiscuous mode (unless it is in MFP mode)
regardless of the vf-true-promisc-support setting.
Now add a VLAN interface on the VF interface::
#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 end result in
this example is that the VF will get all traffic that is tagged with VLAN 100.
Intel Ethernet Flow Director
123-166Intel(R) Ethernet Flow Director
Intel Ethernet Flow Director는 다음 작업을 수행합니다.
- receive packet을 flow에 따라 서로 다른 queue로 보냅니다.
- platform에서 flow routing을 정밀하게 제어합니다.
- flow와 CPU core를 연결해 flow affinity를 제공합니다.
- SFP mode에서 flexible flow classification과 load balancing용 여러 parameter를 지원합니다.
Linux i40e driver는 IPv4, TCPv4, UDPv4 flow type을 지원합니다. 각 type에서 source/destination IP와 source/destination UDP/TCP port를 하나 이상 조합할 수 있습니다.
ethtool `user-def`와 `mask` field로 user-defined flexible 2-byte pattern과 offset에 따라 traffic을 filter할 수 있습니다. L3/L4 flow type만 지원하며, 한 flow type의 input set을 바꾸기 전에 그 type의 모든 Flow Director filter를 지워야 합니다.
Flow Director를 활성화하거나 비활성화합니다.
ethtool -K ethX ntuple <on|off>
ntuple filter를 끄면 사용자가 만든 모든 filter가 driver cache와 hardware에서 제거됩니다. 다시 켠 뒤 필요한 filter를 모두 다시 추가해야 합니다.
packet을 queue 2로 보내는 filter 예시는 다음과 같습니다.
ethtool -N 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]
source와 destination IP만 쓰는 예시는 다음과 같습니다.
ethtool -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 action 2 [loc 1]
현재 filter 목록은 `ethtool -u ethX` 또는 `ethtool -n ethX`로 봅니다.
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.
- Supports multiple parameters for flexible flow classification and load
balancing (in SFP mode only).
NOTE: The Linux i40e driver supports the following flow types: IPv4, TCPv4, and
UDPv4. For a given flow type, it supports valid combinations of IP addresses
(source or destination) and UDP/TCP ports (source and destination). For
example, 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: The Linux i40e 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).
To enable or disable the Intel Ethernet Flow Director::
# ethtool -K ethX ntuple <on|off>
When disabling 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 add a filter that directs packet to queue 2, use -U or -N switch::
# ethtool -N 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 -N ethX flow-type tcp4 src-ip 192.168.10.1 dst-ip \
192.168.10.2 action 2 [loc 1]
To see the list of filters currently present::
# ethtool <-u|-n> ethX
ATR 및 Sideband Perfect Filter
167-236Application Targeted Routing(ATR) Perfect Filter
kernel이 multiple transmit queue mode이면 ATR은 default로 활성화됩니다. TCP-IP flow가 시작될 때 rule을 추가하고 flow가 끝날 때 삭제합니다.
ethtool로 TCP-IP Flow Director rule인 Sideband filter를 추가하면 driver가 ATR을 끕니다. `ethtool -K [adapter] ntuple [off|on]`으로 sideband를 끄면 ATR을 다시 활성화할 수 있습니다.
ATR을 다시 켠 뒤 sideband를 켜도 TCP-IP flow를 추가하기 전까지 ATR은 유지됩니다. 모든 TCP-IP sideband rule을 삭제하면 ATR이 자동으로 다시 활성화됩니다.
ATR rule과 일치한 packet은 ethtool의 `fdir_atr_match` statistic에 집계되며 ATR rule 존재 여부를 확인하는 데도 사용할 수 있습니다.
Sideband Perfect Filter
지정한 특성과 일치하는 traffic을 원하는 queue로 보냅니다. ethtool ntuple interface로 활성화합니다.
ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> \
src-port <port> dst-port <port> action <queue>
- `<device>`: program할 Ethernet device
- `<type>`: ip4, tcp4, udp4 또는 sctp4
- `<ip>`: 일치시킬 IP address
- `<port>`: 일치시킬 port number
- `<queue>`: traffic을 보낼 queue, `-1`이면 matching traffic을 drop
active filter는 `ethtool -u <device>`로 표시하고 `ethtool -U <device> delete <N>`으로 삭제합니다. `<N>`은 목록의 filter ID 또는 추가할 때 `loc <N>`으로 지정한 값입니다.
예를 들어 192.168.0.1:5300에서 192.168.0.5:80으로 가는 TCP traffic을 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
한 flow-type에 program한 모든 filter는 같은 matching input set을 사용해야 합니다. 같은 field에 서로 다른 값을 쓰는 것은 허용하지만, 같은 device에서 tcp4 filter끼리 matching field 구성이 다르면 두 번째 command가 실패합니다.
i40e는 field 일부만 일치시키는 partial mask를 지원하지 않습니다.
Application Targeted Routing (ATR) Perfect Filters
--------------------------------------------------
ATR is enabled by default when the kernel is in multiple transmit queue mode.
An ATR Intel Ethernet Flow Director filter rule is added when a TCP-IP flow
starts and is deleted when the flow ends. When a TCP-IP Intel Ethernet Flow
Director rule is added from ethtool (Sideband filter), ATR is turned off by the
driver. To re-enable ATR, the sideband can be disabled with the ethtool -K
option. For example::
ethtool -K [adapter] ntuple [off|on]
If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a
TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is
automatically re-enabled.
Packets that match the ATR rules are counted in fdir_atr_match stats in
ethtool, which also can be used to verify whether ATR rules still exist.
Sideband Perfect Filters
------------------------
Sideband Perfect Filters are used to direct traffic that matches specified
characteristics. They are enabled through ethtool's ntuple interface. To add a
new filter use the following command::
ethtool -U <device> flow-type <type> src-ip <ip> dst-ip <ip> src-port <port> \
dst-port <port> action <queue>
Where:
<device> - the ethernet device to program
<type> - can be ip4, tcp4, udp4, or sctp4
<ip> - the ip address to match on
<port> - the port number to match on
<queue> - the queue to direct traffic towards (-1 discards matching traffic)
Use the following command to display all of the active filters::
ethtool -u <device>
Use the following command to delete a filter::
ethtool -U <device> 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.
The following example matches TCP traffic sent from 192.168.0.1, port 5300,
directed to 192.168.0.5, port 80, and sends 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
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.
Matching on a sub-portion of a field is not supported by the i40e driver, thus
partial mask fields are not supported.
Flexible data와 VF action encoding
237-291드라이버는 packet payload 안의 user-defined data도 matching할 수 있습니다. ethtool `user-def` field의 상위 부분은 payload offset, 하위 2 bytes는 flexible data입니다.
32-bit 값에서 offset과 matching data가 차지하는 영역입니다.
`user-def 0x4FFFF`는 payload 안쪽 4 bytes 위치에서 `0xFFFF`를 matching합니다. offset 기준은 packet 시작이 아니라 payload 시작입니다.
`flow-type tcp4 ... user-def 0x8BEAF`는 TCP/IPv4 payload의 8-byte 위치에 있는 `0xBEAF`를 matching합니다.
ICMP header는 4-byte header와 4-byte payload로 parse되므로 payload 첫 byte를 matching하려면 offset에 4를 더해야 합니다. ip4 filter는 ICMP frame과 raw unknown ip4 frame을 모두 matching하며 후자는 IP4 frame의 L3 payload를 사용합니다.
최대 offset은 64입니다. hardware는 payload에서 최대 64 bytes만 읽습니다. flexible data가 2 bytes이고 packet payload byte 0에 정렬되어야 하므로 offset은 짝수여야 합니다.
user-defined flexible offset은 input set의 일부라서 같은 type의 여러 filter에 서로 다르게 지정할 수 없습니다. flexible data 자체는 input set이 아니므로 같은 offset에서 서로 다른 data를 matching하는 여러 filter를 만들 수 있습니다.
특정 VF로 traffic을 보내려면 `action`을 64-bit value로 지정합니다. 하위 32 bits는 queue number, 다음 8 bits는 VF를 나타냅니다. 0은 PF이므로 VF identifier에는 1 offset이 적용됩니다.
action 0x800000002
이 값은 VF 7(`8-1`)의 queue 2로 traffic을 보냅니다. 이 filter는 내부 routing rule을 깨뜨리지 않으며 원래 지정 VF로 전달되지 않을 traffic을 새로 route하지 않습니다.
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:
+----------------------------+--------------------------+
| 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.
To create filters that direct traffic to a specific Virtual Function, use the
"action" parameter. Specify the action as a 64 bit value, where the lower 32
bits represents the queue number, while the next 8 bits represent which VF.
Note that 0 is the PF, so the VF identifier is offset by 1. For example::
... action 0x800000002 ...
specifies to direct traffic to Virtual Function 7 (8 minus 1) into queue 2 of
that VF.
Note that these filters will not break internal routing rules, and will not
route traffic that otherwise would not have been sent to the specified Virtual
Function.
Private flag와 link message
292-323`link-down-on-close` private flag
on이면 `ifconfig ethX down`으로 interface를 내릴 때 port link도 내려갑니다.
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX link-down-on-close [on|off]
`mdd-auto-reset-vf` private flag
on이면 malformed descriptor를 감지했을 때 문제 VF를 자동 reset합니다. off이면 문제 VF를 disable합니다.
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX mdd-auto-reset-vf [on|off]
Link message 보기
distribution이 system message를 제한하면 console에 link message가 표시되지 않습니다. network driver link message를 보려면 dmesg level을 8로 설정합니다.
dmesg -n 8
이 설정은 reboot 후 유지되지 않습니다.
Setting the link-down-on-close Private Flag
-------------------------------------------
When the link-down-on-close private flag is set to "on", the port's link will
go down when the interface is brought down using the ifconfig ethX down command.
Use ethtool to view and set link-down-on-close, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX link-down-on-close [on|off]
Setting the mdd-auto-reset-vf Private Flag
------------------------------------------
When the mdd-auto-reset-vf private flag is set to "on", the problematic VF will
be automatically reset if a malformed descriptor is detected. If the flag is
set to "off", the problematic VF will be disabled.
Use ethtool to view and set mdd-auto-reset-vf, as follows::
ethtool --show-priv-flags ethX
ethtool --set-priv-flags ethX mdd-auto-reset-vf [on|off]
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.
Jumbo Frame과 ethtool filtering
324-378Jumbo Frame
MTU를 default `1500`보다 크게 변경하면 Jumbo Frame 지원이 활성화됩니다.
ifconfig eth<x> mtu 9000 up
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
설정은 reboot 후 유지되지 않습니다. RHEL은 `/etc/sysconfig/network-scripts/ifcfg-eth<x>`, SLES는 `/etc/sysconfig/network/<config_file>`에 `MTU=9000`을 추가합니다.
최대 MTU는 `9702`, 최대 Jumbo Frame size는 `9728 bytes`입니다. packet 하나를 수신할 때 page 크기 buffer 여러 개를 사용해 receive packet 할당 중 buffer starvation을 피합니다.
ethtool
driver configuration, diagnostics와 통계 표시에 최신 ethtool이 필요하며 `https://www.kernel.org/pub/software/network/ethtool/`에서 받을 수 있습니다.
Filtering용 command와 option
- `-n --show-nfc`: receive network flow classification 조회
- `rx-flow-hash <type>`: 지정 traffic type의 hash option 조회
- `-N --config-nfc`: receive flow classification 구성
- `rx-flow-hash <type> m|v|t|s|d|f|n|r...`: hash option 구성
- `udp4`, `udp6`: IPv4 또는 IPv6 위의 UDP
- `f`: Rx packet L4 header byte 0,1을 hash
- `n`: Rx packet L4 header byte 2,3을 hash
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 <x> is the interface number::
ifconfig eth<x> mtu 9000 up
Alternatively, you can use the ip command as follows::
ip link set mtu 9000 dev eth<x>
ip link set up dev eth<x>
This setting is not saved across reboots. The setting change can be made
permanent by adding 'MTU=9000' to the file::
/etc/sysconfig/network-scripts/ifcfg-eth<x> // for RHEL
/etc/sysconfig/network/<config_file> // for SLES
NOTE: The maximum MTU setting for Jumbo Frames is 9702. This value coincides
with the maximum Jumbo Frames 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.
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://www.kernel.org/pub/software/network/ethtool/
Supported ethtool Commands and Options for Filtering
----------------------------------------------------
-n --show-nfc
Retrieves the receive network flow classification configurations.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6
Retrieves the hash options for the specified network traffic type.
-N --config-nfc
Configures the receive network flow classification.
rx-flow-hash tcp4|udp4|ah4|esp4|sctp4|tcp6|udp6|ah6|esp6|sctp6 m|v|t|s|d|f|n|r...
Configures the hash options for the specified network traffic type.
udp4 UDP over IPv4
udp6 UDP over IPv6
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.
Speed·Duplex, NAPI와 Flow Control
379-445Speed와 duplex configuration
copper adapter는 기본적으로 link partner와 auto-negotiate해 최적 설정을 찾습니다. 오래된 switch나 강제 설정 switch와 link가 형성되지 않을 때만 adapter와 partner를 동일하게 수동 구성합니다.
1 Gbps 이상은 강제할 수 없으며 autonegotiation advertising으로 구성합니다. XXV710 기반 device는 speed 자체를 설정할 수 없습니다.
speed, duplex, advertising은 ethtool로 구성합니다. 숙련된 administrator만 수동 변경해야 하며 switch와 adapter 설정이 다르면 performance가 저하되거나 동작하지 않을 수 있습니다.
fiber adapter는 full duplex와 native speed로만 동작하므로 auto-negotiate하지 않습니다.
NAPI
i40e driver는 NAPI(Rx polling mode)를 지원합니다. 자세한 내용은 `Documentation/networking/napi.rst`를 참고하십시오.
Flow Control
Ethernet Flow Control(IEEE 802.3x)은 ethtool로 receive/transmit pause frame을 구성합니다. Tx를 켜면 receive packet buffer가 threshold를 넘을 때 pause frame을 생성하고, Rx를 켜면 pause frame의 time delay 동안 transmit unit이 멈춥니다.
flow-control capable link partner가 필요하며 default는 on입니다.
ethtool -A eth? rx <on|off> tx <on|off>
ethtool -s eth? autoneg <on|off>
auto-negotiation이 off일 때 첫 command는 Flow Control을 직접 켜거나 끕니다. auto-negotiation이 on이면 partner와 협상할 parameter를 바꿉니다. Flow Control auto-negotiation은 link auto-negotiation의 일부이며 device에 따라 변경할 수 없을 수 있습니다.
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.
NOTE: You cannot set the speed for devices based on the Intel(R) Ethernet
Network Adapter XXV710 based devices.
Speed, duplex, and autonegotiation advertising are configured through the
ethtool utility.
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.
An Intel(R) Ethernet Network Adapter using fiber-based connections, however,
will not attempt to auto-negotiate with its link partner since those adapters
operate only in full duplex and only at their native speed.
NAPI
----
NAPI (Rx polling mode) is supported in the i40e driver.
See :ref:`Documentation/networking/napi.rst <napi>` for more information.
Flow Control
------------
Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable
receiving and transmitting pause frames for i40e. 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 on by default.
Use ethtool to change the flow control settings.
To enable or disable Rx or Tx Flow Control::
ethtool -A eth? 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.
To enable or disable auto-negotiation::
ethtool -s eth? autoneg <on|off>
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.
RSS, anti-spoofing, PTP와 QinQ
446-499RSS Hash Flow
flow type별 hash byte와 Receive Side Scaling(RSS) hash byte option 조합을 설정할 수 있습니다.
ethtool -N <dev> rx-flow-hash <type> <option>
- `tcp4`, `udp4`, `tcp6`, `udp6`: IPv4/IPv6 위의 TCP/UDP
- `s`: Rx packet의 source IP address를 hash
- `d`: destination IP address를 hash
- `f`: L4 header byte 0,1을 hash
- `n`: L4 header byte 2,3을 hash
MAC 및 VLAN anti-spoofing
악성 driver가 spoofed packet을 보내려 하면 hardware가 drop해 transmit하지 않습니다. 특정 VF에서는 다음처럼 끌 수 있습니다.
ip link set <pf dev> vf <vf id> spoofchk {off|on}
IEEE 1588 PTP Hardware Clock(PHC)
PTP는 computer network의 clock을 동기화합니다. 지원 capability는 device마다 다르므로 `ethtool -T <netdev name>`으로 확정 목록을 확인합니다.
IEEE 802.1ad(QinQ)
QinQ는 Ethernet frame 하나에 여러 VLAN ID, 즉 tag stack을 넣습니다. L2 tunneling과 특정 VLAN 안의 traffic 분리 등에 사용할 수 있습니다.
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입니다. 802.1ad packet에서는 receive checksum offload, cloud filter와 VLAN acceleration을 지원하지 않습니다.
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 <dev> rx-flow-hash <type> <option>
Where <type> is:
tcp4 signifying TCP over IPv4
udp4 signifying UDP over IPv4
tcp6 signifying TCP over IPv6
udp6 signifying UDP 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.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by the
hardware and not transmitted.
NOTE: This feature can be disabled for a specific Virtual Function (VF)::
ip link set <pf dev> vf <vf id> spoofchk {off|on}
IEEE 1588 Precision Time Protocol (PTP) Hardware Clock (PHC)
------------------------------------------------------------
Precision Time Protocol (PTP) is used to synchronize clocks in a computer
network. PTP support varies among Intel devices that support this driver. Use
"ethtool -T <netdev name>" to get a definitive list of PTP capabilities
supported by the 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.
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.
NOTES:
Receive checksum offloads, cloud filters, and VLAN acceleration are not
supported for 802.1ad (QinQ) packets.
Overlay offload와 port당 multiple function
500-542VXLAN 및 GENEVE overlay HW offloading
VXLAN은 L3 network 위로 L2 network를 확장합니다. 일부 Intel Ethernet device는 VXLAN processing을 offload해 CPU utilization을 줄입니다.
VXLAN offload는 ethtool의 Tx/Rx checksum offload option으로 제어됩니다. adapter가 capability를 갖고 Tx checksum offload가 켜져 있으면 VXLAN offload도 활성화됩니다.
VXLAN과 GENEVE HW offload 지원은 kernel의 HW offloading feature 지원에 따라 달라집니다.
Port당 multiple function
일부 X710/XL710 adapter는 physical port 하나에 여러 function을 지원하며 System Setup/BIOS에서 구성합니다.
Minimum TX Bandwidth는 partition이 보장받는 최소 transmit bandwidth를 전체 physical link speed의 percentage로 지정합니다. 값 범위는 `1`부터 `(100 - partition 수) + 1`까지입니다. 예를 들어 partition이 4개면 `1-97`입니다.
Maximum Bandwidth는 partition의 최대 transmit bandwidth를 전체 link speed percentage로 제한하며 범위는 `1-100`입니다. 전체 합은 제한하지 않지만 실제 port 사용량은 100%를 넘지 않습니다.
주의: X710/XXV710에서 MFP와 SR-IOV를 함께 켜면 최대 VF 64개를 활성화하지 못하고 `add vsi failed for VF N, aq_err 16`이 기록됩니다. 64개보다 적은 VF를 사용하십시오.
VXLAN and GENEVE Overlay HW Offloading
--------------------------------------
Virtual Extensible LAN (VXLAN) allows you to extend an L2 network over an L3
network, which may be useful in a virtualized or cloud environment. Some
Intel(R) Ethernet Network devices perform VXLAN processing, offloading it from
the operating system. This reduces CPU utilization.
VXLAN offloading is controlled by the Tx and Rx checksum offload options
provided by ethtool. That is, if Tx checksum offload is enabled, and the
adapter has the capability, VXLAN offloading is also enabled.
Support for VXLAN and GENEVE HW offloading is dependent on kernel support of
the HW offloading features.
Multiple Functions per Port
---------------------------
Some adapters based on the Intel Ethernet Controller X710/XL710 support
multiple functions on a single physical port. Configure these functions through
the System Setup/BIOS.
Minimum TX Bandwidth is the guaranteed minimum data transmission bandwidth, as
a percentage of the full physical port link speed, that the partition will
receive. The bandwidth the partition is awarded will never fall below the level
you specify.
The range for the minimum bandwidth values is:
1 to ((100 minus # of partitions on the physical port) plus 1)
For example, if a physical port has 4 partitions, the range would be:
1 to ((100 - 4) + 1 = 97)
The Maximum Bandwidth percentage represents the maximum transmit bandwidth
allocated to the partition as a percentage of the full physical port link
speed. The accepted range of values is 1-100. The value is used as a limiter,
should you chose that any one particular function not be able to consume 100%
of a port's bandwidth (should it be available). The sum of all the values for
Maximum Bandwidth is not restricted, because no more than 100% of a port's
bandwidth can ever be used.
NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions
per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says
"add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than
64 virtual functions (VFs).
DCB와 interrupt rate limiting
543-595Data Center Bridging(DCB)
DCB는 hardware Quality of Service configuration입니다. VLAN priority tag(802.1p)로 traffic을 8개 priority로 분류합니다.
Priority Flow Control(802.1Qbb)로 network stress 중 packet drop을 줄이거나 없앨 수 있고, 각 priority bandwidth를 hardware level(802.1Qaz)에서 할당합니다.
adapter firmware는 802.1AB LLDP와 802.1Qaz DCBX agent를 구현합니다. firmware DCBX agent는 willing mode로만 동작하며 DCBX-capable peer의 설정을 받을 수 있습니다. dcbtool/lldptool을 통한 software DCBX parameter 구성은 지원하지 않습니다.
private flag `disable-fw-lldp`로 firmware LLDP를 끌 수 있습니다. i40e는 user space가 driver와 통신하고 port DCB configuration을 조회하도록 DCB netlink interface layer를 구현합니다.
kernel은 TC0가 존재한다고 가정합니다. TC0가 없으면 device의 Priority Flow Control을 끄므로 switch에서 DCB를 구성할 때 TC0를 활성화해야 합니다.
Interrupt Rate Limiting
유효 범위는 `0-235 microseconds`, `0=no limit`입니다. XL710 family는 ethtool로 interrupt 사이 microseconds를 제어합니다.
ethtool -C ethX rx-usecs-high N
`0-235` 범위는 초당 약 `4310-250000` interrupt에 해당합니다. `rx-usecs-high`는 `rx-usecs`, `tx-usecs`, adaptive moderation과 독립적입니다. hardware granularity가 4 microseconds이므로 인접한 값이 같은 rate가 될 수 있습니다.
ethtool -C ethX adaptive-rx off adaptive-tx off \
rx-usecs-high 20 rx-usecs 5 tx-usecs 5
이 예시는 adaptive moderation을 끄고 Rx/Tx 완료 표시 지연을 최대 5 microseconds로 두되, `rx-usecs-high=20`으로 전체 interrupt를 초당 50000으로 제한합니다.
Data Center Bridging (DCB)
--------------------------
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).
Adapter firmware implements LLDP and DCBX protocol agents as per 802.1AB and
802.1Qaz respectively. The firmware based DCBX agent runs in willing mode only
and can accept settings from a DCBX capable peer. Software configuration of
DCBX parameters via dcbtool/lldptool are not supported.
NOTE: Firmware LLDP can be disabled by setting the private flag disable-fw-lldp.
The i40e driver implements the DCB netlink interface layer to allow user-space
to communicate with the driver and query DCB configuration for the port.
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.
Interrupt Rate Limiting
-----------------------
:Valid Range: 0-235 (0=no limit)
The Intel(R) Ethernet Controller XL710 family supports an interrupt rate
limiting mechanism. The user can control, via ethtool, the number of
microseconds between interrupts.
Syntax::
# ethtool -C ethX rx-usecs-high N
The range of 0-235 microseconds provides an effective range of 4,310 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.
One possible use case is the following::
# ethtool -C ethX adaptive-rx off adaptive-tx off rx-usecs-high 20 rx-usecs \
5 tx-usecs 5
The above 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.
Performance optimization
596-668Performance optimization
default는 다양한 workload에 맞춰져 있습니다. 추가 최적화가 필요하면 아래 설정을 실험하십시오.
작은 64B frame 성능을 높이려면 BIOS에서 Hyper-Threading을 켜 logical core와 adapter가 사용할 수 있는 queue 수를 늘려 보십시오.
Virtualized environment
- 포함된 `virt_perf_default` script 또는 아래 command로 양쪽의 XPS를 끕니다.
- VM에서 `vcpupin`으로 CPU를 개별 lCPU에 pin하고 device의 `local_cpulist`에 포함된 CPU 집합을 사용합니다.
- VM에 가능한 만큼 Rx/Tx queue를 구성하고 default 1에 의존하지 않습니다.
for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;
do echo 0 > $file; done
local CPU 목록은 `/sys/class/net/<ethX>/device/local_cpulist`에서 확인합니다.
Non-virtualized environment
irqbalance service를 끄고 `set_irq_affinity` script로 adapter IRQ를 특정 core에 pin합니다.
scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]
scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]
첫 command는 모든 core에 고르게, 둘째 command는 adapter와 같은 NUMA node의 local core에 IRQ를 분배합니다. CPU-intensive workload에는 모든 core를 권장합니다.
IP forwarding은 adaptive ITR을 끄고 `rx-usecs=125`, `tx-usecs=125`로 queue당 약 8000 interrupts/sec를 사용합니다.
ethtool -C <interface> adaptive-rx off adaptive-tx off \
rx-usecs 125 tx-usecs 125
낮은 CPU 사용량은 값을 `250`으로 두어 queue당 약 4000 interrupts/sec로 제한합니다. 낮은 latency는 두 값을 `0`으로 설정해 adaptive ITR과 ITR을 끕니다.
ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250 tx-usecs 250
ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0
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.
NOTE: For better performance when processing small (64B) frame sizes, try
enabling Hyper threading in the BIOS in order to increase the number of logical
cores in the system and subsequently increase the number of queues available to
the adapter.
Virtualized Environments
------------------------
1. Disable XPS on both ends by using the included virt_perf_default script
or by running the following command as root::
for file in `ls /sys/class/net/<ethX>/queues/tx-*/xps_cpus`;
do echo 0 > $file; done
2. Using the appropriate mechanism (vcpupin) in the vm, pin the cpu's to
individual lcpu's, making sure to use a set of cpu's included in the
device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist.
3. Configure as many Rx/Tx queues in the VM as available. Do not rely on
the default setting of 1.
Non-virtualized Environments
----------------------------
Pin the adapter's IRQs to specific cores by disabling the irqbalance service
and using the included set_irq_affinity script. Please see the script's help
text for further options.
- The following settings will distribute the IRQs across all the cores evenly::
# scripts/set_irq_affinity -x all <interface1> , [ <interface2>, ... ]
- The following settings will distribute the IRQs across all the cores that are
local to the adapter (same NUMA node)::
# scripts/set_irq_affinity -x local <interface1> ,[ <interface2>, ... ]
For very CPU intensive workloads, we recommend pinning the IRQs to all cores.
For IP Forwarding: Disable Adaptive ITR and lower Rx and Tx interrupts per
queue using ethtool.
- Setting rx-usecs and tx-usecs to 125 will limit interrupts to about 8000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 125 \
tx-usecs 125
For lower CPU utilization: Disable Adaptive ITR and lower Rx and Tx interrupts
per queue using ethtool.
- Setting rx-usecs and tx-usecs to 250 will limit interrupts to about 4000
interrupts per second per queue.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 250 \
tx-usecs 250
For lower latency: Disable Adaptive ITR and ITR by setting Rx and Tx to 0 using
ethtool.
::
# ethtool -C <interface> adaptive-rx off adaptive-tx off rx-usecs 0 \
tx-usecs 0
Application Device Queues
669-739Application Device Queues(ADq)
특정 application에 queue 하나 이상을 전용으로 할당해 latency를 줄이고 application별 Tx rate limit을 적용할 수 있습니다.
1. Traffic class(TC)를 만듭니다. interface당 최대 8개이며 `shaper bw_rlimit`은 optional입니다. 아래 예시는 queue 16개씩 가진 tc0/tc1을 만들고 최대 Tx rate를 각각 1Gbit/3Gbit로 설정합니다.
tc qdisc add dev <interface> root mqprio num_tc 2 \
map 0 0 0 0 1 1 1 1 queues 16@0 16@16 hw 1 mode channel \
shaper bw_rlimit min_rate 1Gbit 2Gbit max_rate 1Gbit 3Gbit
- `map`: 최대 16 priority를 TC에 mapping합니다. 예시는 priority 0-3을 tc0, 4-7을 tc1에 둡니다.
- `queues`: TC별 `<queue 수>@<offset>`입니다. 전체 queue 최대는 64와 core 수 중 작은 값입니다.
- `hw 1 mode channel`: mqprio의 hardware offload mode로 TC, queue와 QoS parameter를 hardware에서 사용합니다.
- `shaper bw_rlimit`: TC별 최소·최대 bandwidth를 설정하며 합계는 port speed 이하여야 합니다.
`min_rate 1Gbit 3Gbit` 같은 bandwidth limit은 `ifstat` 또는 `sar -n DEV [interval] [number of samples]`로 검증합니다.
2. interface에서 HW TC offload를 활성화합니다.
ethtool -K <interface> hw-tc-offload on
3. TC를 interface ingress(RX) flow에 적용합니다.
tc qdisc add dev <interface> ingress
주의사항
- 모든 tc command는 iproute2의 `<pathtoiproute2>/tc/` directory에서 실행합니다.
- ADq는 cloud filter와 호환되지 않습니다.
- mqprio로 TC를 구성하면 ethtool `-L` channel 설정을 지원하지 않습니다.
- 최신 iproute2와 NVM version 6.01 이상이 필요합니다.
- DCB, MFP 또는 Sideband Filter가 켜져 있으면 ADq를 활성화할 수 없습니다.
- DPDK 같은 다른 driver가 cloud filter를 설정했으면 ADq를 활성화할 수 없습니다.
- tunnel filter는 지원하지 않습니다. non-tunnel mode의 encapsulated packet은 outer header를 무시하고 inner header를 matching합니다.
- PF의 TC filter가 VF traffic을 matching하면 PF queue로 route되고 VF에는 전달되지 않아 TCP/IP stack 위에서 drop될 수 있습니다.
- 서로 다른 TC를 가리키는 여러 filter에 matching하면 packet이 복제되어 모든 matching TC queue로 전송됩니다.
Application Device Queues (ADq)
-------------------------------
Application Device Queues (ADq) allows you to dedicate one or more queues to a
specific application. This can reduce latency for the specified application,
and allow Tx traffic to be rate limited per application. Follow the steps below
to set ADq.
1. Create traffic classes (TCs). Maximum of 8 TCs can be created per interface.
The shaper bw_rlimit parameter is optional.
Example: Sets up two tcs, tc0 and tc1, with 16 queues each and max tx rate set
to 1Gbit for tc0 and 3Gbit for tc1.
::
# tc qdisc add dev <interface> root mqprio num_tc 2 map 0 0 0 0 1 1 1 1
queues 16@0 16@16 hw 1 mode channel shaper bw_rlimit min_rate 1Gbit 2Gbit
max_rate 1Gbit 3Gbit
map: priority mapping for up to 16 priorities to tcs (e.g. map 0 0 0 0 1 1 1 1
sets priorities 0-3 to use tc0 and 4-7 to use tc1)
queues: for each tc, <num queues>@<offset> (e.g. queues 16@0 16@16 assigns
16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total
number of queues for all tcs is 64 or number of cores, whichever is lower.)
hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware
offload mode in mqprio that makes full use of the mqprio options, the
TCs, the queue configurations, and the QoS parameters.
shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates.
Totals must be equal or less than port speed.
For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network
monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]`
2. Enable HW TC offload on interface::
# ethtool -K <interface> hw-tc-offload on
3. Apply TCs to ingress (RX) flow of interface::
# tc qdisc add dev <interface> ingress
NOTES:
- Run all tc commands from the iproute2 <pathtoiproute2>/tc/ directory.
- ADq is not compatible with cloud filters.
- Setting up channels via ethtool (ethtool -L) is not supported when the
TCs are configured using mqprio.
- You must have iproute2 latest version
- NVM version 6.01 or later is required.
- ADq cannot be enabled when any the following features are enabled: Data
Center Bridging (DCB), Multiple Functions per Port (MFP), or Sideband
Filters.
- If another driver (for example, DPDK) has set cloud filters, you cannot
enable ADq.
- Tunnel filters are not supported in ADq. If encapsulated packets do
arrive in non-tunnel mode, filtering will be done on the inner headers.
For example, for VXLAN traffic in non-tunnel mode, PCTYPE is identified
as a VXLAN encapsulated packet, outer headers are ignored. Therefore,
inner headers are matched.
- If a TC filter on a PF matches traffic over a VF (on the PF), that
traffic will be routed to the appropriate queue of the PF, and will
not be passed on the VF. Such traffic will end up getting dropped higher
up in the TCP/IP stack as it does not match PF address data.
- If traffic matches multiple TC filters that point to different TCs,
that traffic will be duplicated and sent to all matching TC queues.
The hardware switch mirrors the packet to a VSI list when multiple
filters are matched.
알려진 문제와 troubleshooting
740-770알려진 문제와 troubleshooting
X722 기반 1 Gb device는 다음 기능을 지원하지 않습니다.
- Data Center Bridging(DCB)
- QoS
- VMQ
- SR-IOV
- Task Encapsulation offload(VXLAN, NVGRE)
- Energy Efficient Ethernet(EEE)
- Auto-media detect
kernel driver와 DPDK가 device를 공유할 때의 예기치 않은 문제
i40e device가 multi-driver mode에서 kernel driver와 DPDK driver에 공유되면 global NIC resource 접근이 driver 사이에서 동기화되지 않아 문제가 발생할 수 있습니다.
global register write, AQ를 통한 global configuration, switch mode 변경은 device의 모든 port와 driver에 영향을 줍니다. DPDK를 `multi-driver` module parameter로 load하면 일부 문제를 줄일 수 있습니다.
switch에서 DCB를 구성할 때 TC0를 활성화해야 합니다.
kernel은 TC0가 사용 가능하다고 가정하며, TC0가 없으면 device의 Priority Flow Control을 비활성화합니다.
Known Issues/Troubleshooting
============================
NOTE: 1 Gb devices based on the Intel(R) Ethernet Network Connection X722 do
not support the following features:
* Data Center Bridging (DCB)
* QOS
* VMQ
* SR-IOV
* Task Encapsulation offload (VXLAN, NVGRE)
* Energy Efficient Ethernet (EEE)
* Auto-media detect
Unexpected Issues when the device driver and DPDK share a device
----------------------------------------------------------------
Unexpected issues may result when an i40e device is in multi driver mode and
the kernel driver and DPDK driver are sharing the device. This is because
access to the global NIC resources is not synchronized between multiple
drivers. Any change to the global NIC configuration (writing to a global
register, setting global configuration by AQ, or changing switch modes) will
affect all ports and drivers on the device. Loading DPDK with the
"multi-driver" module parameter may mitigate some of the issues.
TC0 must be enabled when setting up DCB on a switch
---------------------------------------------------
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.
지원
771-778지원
일반 정보는 Intel support website `https://www.intel.com/support/`를 참고하십시오.
지원되는 adapter와 kernel에서 공개 source code의 문제가 확인되면 구체적인 정보를 `[email protected]`로 보내십시오.
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 [email protected].
요약·해설
i40e.rst:1-778i40e는 700 Series의 PF·VF traffic steering부터 Flow Director, DCB, overlay offload와 application별 queue까지 폭넓게 제어합니다. 여러 기능이 global device state와 queue resource를 공유하므로 filter input set, MFP·ADq 호환성, TC0와 driver 간 동기화 제약을 함께 확인해야 합니다.
driver scope와 optical module 운용 조건입니다.
trust, promiscuous 유형과 VLAN interface를 단계적으로 설정합니다.
ntuple과 sideband rule이 ATR 상태에 미치는 영향입니다.
payload matching field의 encoding과 제약입니다.
interface close와 malformed descriptor 처리 정책입니다.
frame 크기와 pause-frame 운용 조건입니다.
protocol별 지원과 주요 제한입니다.
physical port partition의 보장량과 상한입니다.
priority 분류, flow control과 bandwidth enforcement 관계입니다.
latency, CPU와 rate cap의 대표 설정입니다.
virtualized와 bare-metal에서 queue와 core locality를 맞춥니다.
mqprio TC와 hardware offload를 결합해 application 전용 queue를 만듭니다.
기능 조합과 device별 주의사항입니다.