From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: [PATCH 2/4 v2] PCI: support ARI capability Date: Wed, 10 Sep 2008 11:42:18 -0700 Message-ID: References: <7A25B56E4BE99C4283EB931CD1A40E110177EB6E@pdsmsx414.ccr.corp.intel.com> <20080901152734.GC16796@ldl.fc.hp.com> <7A25B56E4BE99C4283EB931CD1A40E110181CAF7@pdsmsx414.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Alex Chiang" , "Jesse Barnes" , , "Randy Dunlap" , "Greg KH" , "Grant Grundler" , "Matthew Wilcox" , , , , To: "Zhao\, Yu" Return-path: In-Reply-To: <7A25B56E4BE99C4283EB931CD1A40E110181CAF7@pdsmsx414.ccr.corp.intel.com> (Yu Zhao's message of "Wed, 10 Sep 2008 15:48:04 +0800") Sender: linux-pci-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > ARI is an independent PCI Express extended capability. Multi-function > devices supporting this capability may use it to track dependency > between different functions and assign function group numbers to > these functions. > Another reason to keep this separated with SR-IOV is that after ARI > is enabled, PCI Express Endpoint may have non-zero slot number > (device number), which is different from traditional PCI Express > Endpoint. OK, I guess. Although I still don't see why we need a user-visible option to control ARI independent of SR-IOV. When would a user want to enable CONFIG_PCI_ARI=y but not select CONFIG_PCI_IOV? (Also, by the way, why PCI_IOV instead of PCI_SR_IOV -- I assume in the future we may have PCI_MR_IOV, and matching the PCI terminology is probably easier for people to understand). - R.