lkml.org 
[lkml]   [2008]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support
While we are arguing what the software model the SR-IOV should be, let 
me ask two simple questions first:

1, What does the SR-IOV looks like?
2, Why do we need to support it?

I'm sure people have different understandings from their own view
points. No one is wrong, but, please don't make thing complicated and
don't ignore user requirements.

PCI SIG and hardware vendors create such thing intending to make
hardware resource in one PCI device be shared from different software
instances -- I guess all of us agree with this. No doubt PF is real
function in the PCI device, but VF is different? No, it also has its own
Bus, Device and Function numbers, and PCI configuration space and Memory
Space (MMIO). To be more detailed, it can response to and initiate PCI
Transaction Layer Protocol packets, which means it can do everything a
PF can in PCI level. From these obvious behaviors, we can conclude PCI
SIG model VF as a normal PCI device function, even it's not standalone.

As you know the Linux kernel is the base of various virtual machine
monitors such as KVM, Xen, OpenVZ and VServer. We need SR-IOV support in
the kernel because mostly it helps high-end users (IT departments, HPC,
etc.) to share limited hardware resources among hundreds or even
thousands virtual machines and hence reduce the cost. How can we make
these virtual machine monitors utilize the advantage of SR-IOV without
spending too much effort meanwhile remaining architectural correctness?
I believe making VF represent as much closer as a normal PCI device
(struct pci_dev) is the best way in current situation, because this is
not only what the hardware designers expect us to do but also the usage
model that KVM, Xen and other VMMs have already supported.

I agree that API in the SR-IOV pacth is arguable and the concerns such
as lack of PF driver, etc. are also valid. But I personally think these
stuff are not essential problems to me and other SR-IOV driver
developers. People can refine things but don't want to recreate things
in another totally different way especially that way doesn't bring them
obvious benefits.

As I can see that we are now reaching a point that a decision must be
made, I know this is such difficult thing in an open and free community
but fortunately we have a lot of talented and experienced people here.
So let's make it happen, and keep our loyal users happy!

Thanks,
Yu


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