Open Stack

As for the scalability issue, boris, are you talking about the VF number issue, i.e. A physical PCI devices can at most have 256 virtual functions? 

I think we have discussed this before. We should keep the compute node to manage the same VF functions, so that VFs belongs to the same PF will have only one entry in DB, with a field indicating the number of free VFs. Thus there will be no scalability issue because the number of PCI slot is limited.

We didn't implement this mechanism on current patch set because we agree to make it a  enhancement. If it's really a concern, please raise it and we will enhance our resource tracker for this. That's not complex task.

Thanks
--jyh

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Monday, July 22, 2013 8:22 AM
> To: Jiang, Yunhong
> Cc: boris at pavlovic.me; openstack-dev at lists.openstack.org
> Subject: Re: The PCI support blueprint
> 
> On 07/22/2013 11:17 AM, Jiang, Yunhong wrote:
> > Hi, Boris
> > 	I'm a surprised that you want to postpone the PCI support
> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base) to I
> release. You and our team have been working on this for a long time, and
> the patches has been reviewed several rounds. And we have been waiting
> for your DB layer patch for two weeks without any update.
> >
> > 	Can you give more reason why it's pushed to I release? If you are out
> of bandwidth, we are sure to take it and push it to H release!
> >
> > 	Is it because you want to base your DB layer on your 'A simple way to
> improve nova scheduler'? That really does not make sense to me. Firstly,
> that proposal is still under early discussion and get several different voices
> already, secondly, PCI support is far more than DB layer, it includes
> resource tracker, scheduler filter, libvirt support enhancement etc. Even if
> we will change the scheduler that way after I release, we need only
> change the DB layer, and I don't think that's a big effort!
> 
> Boris mentioned scalability concerns with the current approach on IRC.
> I'd like more detail.
> 
> In general, if we can see a reasonable path to upgrade what we have now
> to make it better in the future, then we don't need to block it because
> of that.  If the current approach will result in a large upgrade impact
> to users to be able to make it better, that would be a reason to hold
> off.  It also depends on how serious the scalability concerns are.
> 
> --
> Russell Bryant