svn commit: r209611 - head/sys/dev/e1000

Jack Vogel jfvogel at gmail.com
Wed Jun 30 22:13:24 UTC 2010


On Wed, Jun 30, 2010 at 2:50 PM, Julian Elischer <julian at elischer.org>wrote:

> On 6/30/10 10:26 AM, Jack F Vogel wrote:
>
>> Author: jfv
>> Date: Wed Jun 30 17:26:47 2010
>> New Revision: 209611
>> URL: http://svn.freebsd.org/changeset/base/209611
>>
>> Log:
>>   SR-IOV support added to igb
>>
>>   What this provides is support for the 'virtual function'
>>   interface that a FreeBSD VM may be assigned from a host
>>   like KVM on Linux, or newer versions of Xen with such
>>   support.
>>
>>   When the guest is set up with the capability, a special
>>   limited function 82576 PCI device is present in its virtual
>>   PCI space, so with this driver installed in the guest that
>>   device will be detected and function nearly like the bare
>>   metal, as it were.
>>
>>   The interface is only allowed a single queue in this configuration
>>   however initial performance tests have looked very good.
>>
>>   Enjoy!!
>>
>>
> do these extra devices turn up in a standard ifconfig output?
> in other words, can we assign them to jails using vimage?
>
>
They only show up if configured in the PF host, for instance if using Linux
and KVM (I did develop and test
with Fedora 13) you must load the igb driver there specifying that you want
vf's created and how many.
Next in the management of the guest you need to assign one of these vf
devices to the guest. After you
do all that and load this igb driver then yes, it will look just like a
standard igbX device.

Not sure if I understand your question, did any of that help? If you mean
can FreeBSD make
multiple VF's and then manage them with jails, no, that would be to have PF
support, and to
do that I need SRIOV support in the kernel/pci subsystem.

Now, if someone were interested in actually doing that then I'd be happy to
implement the full
PF/VF capability the way Linux has, but that's a bigger lift. Just let me
know if we want to
go in that direction.

Jack


More information about the svn-src-head mailing list