FreeBSD manual
download PDF document: iavf.4.pdf
IAVF(4) FreeBSD Kernel Interfaces Manual IAVF(4)
NAME
iavf - Intel Ethernet Adaptive Virtual Function Driver
SYNOPSIS
To compile this driver into the kernel, place the following lines in your
kernel configuration file:
device iflib
device iavf
To load the driver as a module at boot time, place the following lines in
loader.conf(5):
if_iavf_load="YES"
DESCRIPTION
The iavf driver provides support for any PCI Virtual Function created
from certain Intel Ethernet devices. This driver is compatible with
virtual functions bound to devices based on the following:
o Intel(R) Ethernet Controller E810-C
o Intel(R) Ethernet Controller E810-XXV
o Intel(R) Ethernet Connection E822-C
o Intel(R) Ethernet Connection E822-L
o Intel(R) Ethernet Connection E823-C
o Intel(R) Ethernet Connection E823-L
o Intel(R) Ethernet Controller I710
o Intel(R) Ethernet Controller X710
o Intel(R) Ethernet Controller XL710
o Intel(R) Ethernet Network Connection X722
o Intel(R) Ethernet Controller XXV710
o Intel(R) Ethernet Controller V710
The associated Physical Function (PF) drivers for this VF driver are:
o ice(4)
o ixl(4)
For questions related to hardware requirements, refer to the
documentation supplied with your Intel Ethernet Adapter. All hardware
requirements listed apply to use with FreeBSD.
The VF Driver
The VF driver is normally used in a virtualized environment where a host
driver manages SR-IOV, and provides a VF device to the guest.
In the FreeBSD guest, the iavf driver would be loaded and will function
using the VF device assigned to it.
The VF driver provides most of the same functionality as the core driver,
but is actually a subordinate to the host. Access to many controls is
accomplished by a request to the host via what is called the "Admin
queue." These are startup and initialization events, however; once in
operation, the device is self-contained and should achieve near native
performance.
Some notable limitations of the VF environment:
Adaptive Virtual Function
Adaptive Virtual Function (AVF) allows the virtual function driver, or
VF, to adapt to changing feature sets of the physical function driver
(PF) with which it is associated. This allows system administrators to
update a PF without having to update all the VFs associated with it. All
AVFs have a single common device ID and branding string.
AVFs have a minimum set of features known as "base mode," but may provide
additional features depending on what features are available in the PF
with which the AVF is associated. The following are base mode features:
o 4 Queue Pairs (QP) and associated Configuration Status Registers
(CSRs) for Tx/Rx
o iavf descriptors and ring format
o Descriptor write-back completion
o 1 control queue, with iavf descriptors, CSRs and ring format
o 5 MSI-X interrupt vectors and corresponding iavf CSRs
o 1 Interrupt Throttle Rate (ITR) index
o 1 Virtual Station Interface (VSI) per VF
o 1 Traffic Class (TC), TC0
o Receive Side Scaling (RSS) with 64 entry indirection table and key,
configured through the PF
o 1 unicast MAC address reserved per VF
o 8 MAC address filters for each VF on an Intel(R) Ethernet 800 Series
device
o 16 MAC address filters for each VF on an Intel(R) Ethernet 700 Series
device
o Stateless offloads - non-tunneled checksums
o AVF device ID
o HW mailbox is used for VF to PF communications
CONFIGURATION AND TUNING
Important System Configuration Changes
It is important to note that 100G operation can generate high numbers of
interrupts, often incorrectly being interpreted as a storm condition in
the kernel. It is suggested that this be resolved by setting
hw.intr_storm_threshold to 0.
The default is 1000.
Best throughput results are seen with a large MTU; use 9706 if possible.
The default number of descriptors per ring is 1024. Increasing this may
improve performance, depending on your use case.
Configuring for no iflib
iflib(4) is a common framework for network interface drivers for FreeBSD
that uses a shared set of sysctl names.
The default iavf driver depends on it, but it can be compiled without it.
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(8) command to increase the MTU size.
To confirm the MTU used between two specific devices, use route(8):
route get <destination_IP_address>
receive each jumbo packet. This should help to avoid buffer
starvation issues when allocating receive packets.
o 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.
Checksum Offload
Checksum offloading supports both TCP and UDP packets and is supported
for both transmit and receive.
TSO (TCP Segmentation Offload) supports both IPv4 and IPv6. Both of
these features are enabled and disabled via ifconfig(8).
NOTE:
o TSO requires Tx checksum; if Tx checksum is disabled then TSO will
also be disabled.
LRO
LRO (Large Receive Offload) may provide Rx performance improvement.
However, it is incompatible with packet-forwarding workloads. You should
carefully evaluate the environment and enable LRO when possible.
Rx and Tx Descriptor Rings
Allows you to set the Rx and Tx descriptor rings independently. Set them
via these iflib(4) sysctls:
dev.iavf.#.iflib.override_nrxds
dev.iavf.#.iflib.override_ntxds
Link-Level Flow Control (LFC)
The VF driver does not have access to flow control settings. It must be
managed from the host side.
SEE ALSO
arp(4), ice(4), iflib(4), ixl(4), netintro(4), vlan(4), ifconfig(8)
See the "Intel(R) Ethernet Adapters and Devices User Guide" for
additional information on features. It is available on the Intel website
at either of the following:
o https://cdrdv2.intel.com/v1/dl/getContent/705831
o https://www.intel.com/content/www/us/en/download/19373/adapter-user-guide-for-intel-ethernet-adapters.html
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
<http://www.intel.com/support>
CAVEATS
Driver Buffer Overflow Fix
The fix to resolve CVE-2016-8105, referenced in Intel SA-00069
<https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00069.html>,
is included in this and future versions of the driver.
Network Memory Buffer Allocation
FreeBSD may have a low number of network memory buffers (mbufs) by
default. If your mbuf value is too low, it may cause the driver to fail
kern.ipc.nmbjumbo9
kern.ipc.nmbjumbo16
kern.ipc.nmbufs
The amount of memory that you allocate is system specific, and may
require some trial and error. Also, increasing the following in
sysctl.conf(5) could help increase network performance:
kern.ipc.maxsockbuf
net.inet.tcp.sendspace
net.inet.tcp.recvspace
net.inet.udp.maxdgram
net.inet.udp.recvspace
UDP Stress Test Dropped Packet Issue
Under small packet UDP stress with the iavf driver, the system may drop
UDP packets due to socket buffers being full. Setting the PF driver's
Flow Control variables to the minimum may resolve the issue.
Disable LRO when routing/bridging
LRO must be turned off when forwarding traffic.
SUPPORT
For general information, go to the Intel support website at
<http://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 <freebsd@intel.com>.
LEGAL
Intel(R) 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.
HISTORY
The iavf device driver first appeared in FreeBSD 10.1 under the name
ixlv. It was converted to use iflib(4) and renamed in FreeBSD 12.4.
AUTHORS
The iavf driver was written by the Intel Corporation <freebsd@intel.com>
FreeBSD 14.2-RELEASE May 21, 2024 FreeBSD 14.2-RELEASE