Ian, thanks for your reply. Please check comments prefix with [yjiang5]. Thanks --jyh
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Friday, January 10, 2014 12:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support Hey Yunhong, The thing about 'group' and 'flavor' and 'whitelist' is that they once meant distinct things (and I think we've been trying to reduce them back from three things to two or one): - group: equivalent devices at a host level - use any one, no-one will care, because they're either identical or as near as makes no difference - flavor: equivalent devices to an end user - we may re-evaluate our offerings and group them differently on the fly - whitelist: either 'something to match the devices you may assign' (originally) or 'something to match the devices you may assign *and* put them in the group (in the group proposal) [yjiang5] Really thanks for the summary and it is quite clear. So what's the object of "equivalent devices at host level"? Because 'equivalent device * to an end user *" is flavor, so is it 'equivalent to *scheduler*" or 'equivalent to *xxx*'? If equivalent to scheduler, then I'd take the pci_stats as a flexible group for scheduler, and I'd think 'equivalent for scheduler' as a restriction for 'equivalent to end user' because of performance issue, otherwise, it's needless. Secondly, for your definition of 'whitelist', I'm hesitate to your '*and*' because IMHO, 'and' means mixed two things together, otherwise, we can state in simply one sentence. For example, I prefer to have another configuration option to define the 'put devices in the group', or, if we extend it , be "define extra information like 'group name' for devices". Bearing in mind what you said about scheduling, and if we skip 'group' for a moment, then can I suggest (or possibly restate, because your comments are pointing in this direction): - we allow extra information to be added at what is now the whitelisting stage, that just gets carried around with the device [yjiang5] For 'added at ... whitelisting stage', see my above statement about the configuration. However, if you do want to use whitelist, I'm ok, but please keep in mind that it's two functionality combined: device you may assign *and* the group name for these devices. - when we're turning devices into flavors, we can also match on that extra information if we want (which means we can tag up the devices on the compute node if we like, according to taste, and then bundle them up by tag to make flavors; or we can add Neutron specific information and ignore it when making flavors) [yjiang5] Agree. Currently we can only use vendor_id and device_id for flavor/alias, but we can extend it to cover such extra information since now it's a API. - we would need to add a config param on the control host to decide which flags to group on when doing the stats (and they would additionally be the only params that would work for flavors, I think) [yjiang5] Agree. And this is achievable because we switch the flavor to be API, then we can control the flavor creation process.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
