Date:	Fri, 07 Nov 2008 23:17:40 +0800
From:	Yu Zhao <yu.zhao@...scape.net>
To:	Greg KH <greg@...ah.com>, Matthew Wilcox <matthew@....cx>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	"Fischer, Anna" <anna.fischer@...com>, H L <swdevyid@...oo.com>,
	"randy.dunlap@...cle.com" <randy.dunlap@...cle.com>,
	"grundler@...isc-linux.org" <grundler@...isc-linux.org>,
	"Chiang, Alexander" <achiang@...com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"rdreier@...co.com" <rdreier@...co.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>, keir.fraser@...citrix.com,
	Leonid.Grossman@...erion.com, eddie.dong@...el.com,
	jun.nakajima@...el.com, avi@...hat.com
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists