<div dir="ltr">On 11 January 2014 00:04, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="ZH-CN">
<div><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">[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 *<b>scheduler</b>*” or ‘equivalent to *<b>xxx</b>*’? If equivalent to scheduler, then I’d take the pci_stats as a flexible group for scheduler</span></div></div>

</blockquote><div><br></div><div>To the scheduler, indeed.  And with the group proposal the scheduler and end user equivalences are one and the same.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div link="blue" vlink="purple" lang="ZH-CN"><div><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">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”.</span></div></div></blockquote><div>

<br></div><div>I'm not stating what we should do, or what the definitions should mean; I'm saying how they've been interpreted as weve discussed this in the past.  We've had issues in the past where we've had continuing difficulties in describing anything without coming back to a 'whitelist' (generally meaning 'matching expression, as an actual 'whitelist' is implied, rather than separately required, in a grouping system.<br>

<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="ZH-CN"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<div><div><div><div class="im">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"> </span><span lang="EN-US">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):</span>

</p></div><div><div class="im">
<p class="MsoNormal"><span lang="EN-US">- we allow extra information to be added at what is now the whitelisting stage, that just gets carried around with the device<u></u><u></u></span></p>
</div><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">[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 *<b>and</b>* the group name for these devices.</span></p></div></div></div></div></div></div></div></blockquote><div><br></div><div>Indeed - which is in fact what we've been proposing all along.<br>

 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="ZH-CN"><div><div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">

<div><div><div><div><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p><span lang="EN-US">- 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)</span>
</div><div><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">[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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US"><u></u> <u></u></span></p>
</div>
<div><div class="im">
<p class="MsoNormal"><span lang="EN-US">- 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)<u></u><u></u></span></p>


</div><p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d" lang="EN-US">[yjiang5] Agree. And this is achievable because we switch the flavor to be API, then we can control the flavor creation process.</span></p>

</div></div></div></div></div></div></div></blockquote><div><br></div><div>OK -  so if this is good then I think the question is how we could change the 'pci_whitelist' parameter we have - which, as you say, should either *only* do whitelisting or be renamed - to allow us to add information.  Yongli has something along those lines but it's not flexible and it distinguishes poorly between which bits are extra information and which bits are matching expressions (and it's still called pci_whitelist) - but even with those criticisms it's very close to what we're talking about.  When we have that I think a lot of the rest of the arguments should simply resolve themselves.<br>

-- <br></div><div>Ian.<br></div></div></div></div>