os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Add a 2014Q1 report on the PCI SR-IOV infrastructure

Browse source 
Submitted by:	rstone
This commit is contained in:
Gabor Pali 2014-03-31 19:55:44 +00:00
parent bf598f94a3
commit 1194095c70
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44402
1 changed files with 69 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

70
en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml
View file

@ -18,7 +18,7 @@
<!-- XXX: Keep the number of entries updated -->
<p>Thanks to all the reporters for the excellent work! This report
contains 6 entries and we hope you enjoy reading it.</p>
contains 7 entries and we hope you enjoy reading it.</p>
<p>The deadline for submissions covering between April and
June 2014 is July 7th, 2014.</p>
@ -30,6 +30,12 @@
<description>&os; Team Reports</description>
</category>
<category>
<name>kern</name>
<description>Kernel</description>
</category>
<category>
<name>ports</name>
@ -377,4 +383,66 @@
Midori).</task>
</help>
</project>
<project cat='kern'>
<title>PCI SR-IOV Infrastructure</title>
<contact>
<person>
<name>
<given>Ryan</given>
<common>Stone</common>
</name>
<email>rstone@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://github.com/rysto32/freebsd/tree/iov_ixgbe">Work in progress on GitHub</url>
</links>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>At this point only SR-IOV support for the <tt>ixgbe(4)</tt>
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.</p>
<p>At present, <tt>ixgbe(4)</tt> is able to create VFs and the
<tt>ixgbevf</tt> 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.</p>
</body>
<sponsor>Sandvine, Inc</sponsor>
</project>
</report>