svn commit: r44402 - head/en_US.ISO8859-1/htdocs/news/status

Gabor Pali pgj at
Mon Mar 31 19:55:45 UTC 2014

Author: pgj
Date: Mon Mar 31 19:55:44 2014
New Revision: 44402

  - Add a 2014Q1 report on the PCI SR-IOV infrastructure
  Submitted by:	rstone


Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml
--- head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml	Mon Mar 31 18:52:57 2014	(r44401)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml	Mon Mar 31 19:55:44 2014	(r44402)
@@ -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>
@@ -31,6 +31,12 @@
+    <name>kern</name>
+    <description>Kernel</description>
+  </category>
+  <category>
@@ -377,4 +383,66 @@
+  <project cat='kern'>
+    <title>PCI SR-IOV Infrastructure</title>
+    <contact>
+      <person>
+	<name>
+	  <given>Ryan</given>
+	  <common>Stone</common>
+	</name>
+	<email>rstone at</email>
+      </person>
+    </contact>
+    <links>
+      <url href="">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>

More information about the svn-doc-all mailing list