From owner-svn-doc-head@FreeBSD.ORG Mon Mar 31 19:55:45 2014
Return-Path: Thanks to all the reporters for the excellent work! This report
- contains 6 entries and we hope you enjoy reading it.
The deadline for submissions covering between April and June 2014 is July 7th, 2014.
@@ -31,6 +31,12 @@PCI Single Root I/O Virtualization (SR-IOV) is an optional part + of the PCIe standard that provides hardware acceleration for the + virtualization of PCIe devices. When SR-IOV is in use, a + function in a PCI device (known as a Physical Function, or PF) + will present multiple Virtual PCI Functions (VF) on the PCI bus. + These VFs are fully independent PCI devices that have + access to the resources of the PF. For example, on a network + interface card VFs could transmit and receive packets + independent of the PF.
+ +The most obvious use case for SR-IOV is virtualization. A + hypervisor like bhyve could instantiate a VF for every VM and + use PCI passthrough to assign the VFs to the VMs. This would + allow multiple VMs to share access to the PCI device without + having to do any expensive communication with the hypervisor, + greatly increasing performance of performing I/O from a VM.
+ +There are two parts to this project. The first is implementing + an API in the PCI subsystem for the creating VFs and configuring + standard PCI features like BARs. The second part is updating + individual drivers for PCI devices that support SR-IOV to + configure their VFs. For example, a network interface driver + will typically have to assign a MAC address to a VF and + configure the interface to route packets destined for that MAC + address to the VF.
+ +At this point only SR-IOV support for the ixgbe(4) + driver is planned. The PCI subsystem API is designed to be + generic and should support SR-IOV on any device, but fairly + extensive driver work is necessary to support SR-IOV, which is + currently not planned due to lack of time and hardware.
+ +At present, ixgbe(4) is able to create VFs and the + ixgbevf driver is able to pass traffic. There is still + a fair amount of work to support VLAN tags, multicast addresses + and other features on the VFs. Also, the VF configuration needs + to be better integrated with the PF initialization path to + ensure that resets of the PF do not interrupt operation of the + VFs.
+ + +