IAVF(4)

πŸ’– IAVF β€” the Intel Adaptive Virtual Function driver πŸ’–

okay bestie, gather round, because we're talking about iavf(4) β€” that's the Intel Adaptive Virtual Function driver, and she is iconic. this is the kernel interfaces manual page, and yes, we're reading it together, no skipping, periodt. 🫢


✨ SYNOPSIS ✨

so like, you wanna get this driver into your kernel? say less. drop these lines into your kernel configuration file:

device iflib
device iavf

and if you'd rather load it as a module at boot time instead (valid, honestly), put this in loader.conf(5):

if_iavf_load="YES"

slay. that's it. that's the setup. πŸ’…


🌸 DESCRIPTION 🌸

okay so here's the tea: the iavf driver gives you support for the PCI Virtual Functions from the 700 Series of ethernet devices and newer product families. she's not a one-trick pony either β€” look at this feature list, it's giving overachiever:

  • Jumbo Frames
  • TX/RX checksum offload
  • TCP segmentation offload (TSO)
  • Large Receive Offload (LRO)
  • VLAN tag insertion/extraction
  • VLAN checksum offload
  • VLAN TSO
  • Receive Side Steering (RSS)

and the best part? all of that for both IPv4 and IPv6. we love an inclusive queen. 🌈

want more hardware lore or got questions about hardware requirements? the vibe check lives at http://support.intel.com/.

Jumbo Frames support? that's handled through the interface MTU setting, ngl. pick an MTU larger than 1500 bytes using the ifconfig(8) utility and boom, the adapter is configured to receive and transmit Jumbo Frames. the max MTU size for Jumbo Frames is 9706. remember that number, it's not vibes, it's a fact. ✨

offloads are also controlled via the interface, fr fr. for instance, checksumming for both IPv4 and IPv6 can be set and unset, TSO4 and/or TSO6, and finally LRO can be set and unset. very much choose-your-own-adventure.

for more info on configuring this device, go see ifconfig(8).

NOTE: bestie, listen. this iavf driver is only for Virtual Functions. if you're dealing with 700 series Physical Functions, you want the ixl(4) driver instead. don't mix them up, i'm begging. 😭

πŸŽ€ LOADER TUNABLES πŸŽ€

tunables can be set at the loader(8) prompt before booting the kernel, or stored in loader.conf(5). your call, both are valid.

  • hw.iavf.rx_itr β€” the RX interrupt rate value. set to 62 (124 usec) by default.
  • hw.iavf.tx_itr β€” the TX interrupt rate value. set to 122 (244 usec) by default.
  • hw.iavf.enable_head_writeback β€” when the driver is finding the last TX descriptor processed by the hardware, this makes it use a value written to memory by the hardware instead of scanning the descriptor ring for completed descriptors. disabled by default β€” and when it's on, it mimics the "legacy" TX behavior found in ixgbe(4), to ensure compatibility with future, non-700 series VF devices. iykyk. πŸ”₯

πŸ’œ SUPPORT πŸ’œ

need general info or support? go to the Intel support website at http://support.intel.com/. πŸ¦‹

and if you've identified an issue with this driver on a supported adapter, email all the specific information related to the issue to freebsd@intel.com. they want the details, bestie, don't be shy.


⭐ SEE ALSO ⭐


🌸 HISTORY 🌸

the iavf device driver first appeared in FreeBSD 10.1 β€” under the name "ixlv", if you can believe it. glow-up era. she was then converted to use iflib(9) and changed to her current name in FreeBSD 12. character development, honestly. πŸ‘‘


πŸ’– AUTHORS πŸ’–

the iavf driver was written by Jack Vogel <jfv@freebsd.org> and Eric Joyner <erj@freebsd.org>. legends, both of them. 🫢


🧚 CAVEATS 🧚

so like, this driver is supposed to function on VFs spawned from future network devices by Intel β€” but at the time of this writing, it's only been tested on the 700 series VFs. future-proofing in theory, tested-in-the-wild in practice. no cap. πŸ™ˆ


and that's the whole page, babe! this one's from the Debian edition, dated January 30, 2019 β€” so if you're citing it, that's the source and the date. mwah, go configure your interfaces. πŸ’…πŸ’–βœ¨

πŸ“¦ where this page comes from