[lkml]   [2008]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

> -----Original Message-----
> From: Fischer, Anna []
> Sent: Saturday, November 08, 2008 3:10 AM
> To: Greg KH; Yu Zhao
> Cc: Matthew Wilcox; Anthony Liguori; H L;;
>; Chiang, Alexander;;
>;; Leonid Grossman;
> Subject: RE: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

> > But would such an api really take advantage of the new IOV
> > that are exposed by the new device type?
> I agree with what Yu says. The idea is to have hardware capabilities
> virtualize a PCI device in a way that those virtual devices can
> full PCI devices. The advantage of that is that those virtual device
> then be used like any other standard PCI device, meaning we can use
> existing
> OS tools, configuration mechanism etc. to start working with them.
> when
> using a virtualization-based system, e.g. Xen or KVM, we do not need
> to introduce new mechanisms to make use of SR-IOV, because we can
> VFs as full PCI devices.
> A virtual PCI device in hardware (a VF) can be as powerful or complex
> you like, or it can be very simple. But the big advantage of SR-IOV is
> that hardware presents a complete PCI device to the OS - as opposed to
> some resources, or queues, that need specific new configuration and
> assignment mechanisms in order to use them with a guest OS (like, for
> example, VMDq or similar technologies).
> Anna

Taking netdev interface as an example - a queue pair is a great way to
scale across cpu cores in a single OS image, but it is just not a good
way to share device across multiple OS images.
The best unit of virtualization is a VF that is implemented as a
complete netdev pci device (not a subset of a pci device).
This way, native netdev device drivers can work for direct hw access to
a VF "as is", and most/all Linux networking features (including VMQ)
will work in a guest.
Also, guest migration for netdev interfaces (both direct and virtual)
can be supported via native Linux mechanism (bonding driver), while Dom0
can retain "veto power" over any guest direct interface operation it
deems privileged (vlan, mac address, promisc mode, bandwidth allocation
between VFs, etc.).


 \ /
  Last update: 2008-11-08 16:41    [W:0.153 / U:2.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site