<div dir="ltr">On 27 January 2014 15:58, Robert Li (baoli) <span dir="ltr"><<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Hi Folks,</div>
<div><br>
</div>
<div>In today's meeting, we discussed a scheduler issue for SRIOV. The basic requirement is for coexistence of the following compute nodes in a cloud:</div>
<div>      -- SRIOV only compute nodes</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">


<div>      -- non-SRIOV only compute nodes</div>
<div>      -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of a proper name, let's call them compute nodes with hybrid NICs support, or simply hybrid compute nodes.</div>
<div><br>
</div>
<div>I'm not sure if it's practical in having hybrid compute nodes in a real cloud. But it may be useful in the lab to bench mark the performance differences between SRIOV, non-SRIOV, and coexistence of both.</div>

</div></blockquote><div><br></div><div>I think in fact hybrid nodes would be the common case  - there's nothing wrong with mixing virtual and physical NICs in a VM and it's been the general case we've been discussing till now.  VMs that *only* support SRIOV and have no soft switch sound like a complete outlier to me.  I'm assuming that passthrough devices are a scarce resource and you wouldn't want to waste them on a low traffic control connection, so you would always have a softswitch on the host to take care of such cases.<br>

<br><div>I believe there *is* a use case here when  you have some, but not all, machines that have SRIOV devices.  
They will also have a softswitch of some sort and are therefore not only
 'SRIOV only' in that sense.  But the point is that if you have a 
limited SRIOV resource you may want to preserve these machines for VMs 
that have SRIOV requirements, and avoid mapping general VMs with no 
SRIOV requirements onto them.<br><br></div><div>You can expand the problem further and avoid loading up machines with specific PCI devices of any sort 
if you have a VM that doesn't need a device of that sort, which comes 
down to prioritising your machines at schedule time based on whether 
they're a good fit for the VM you intend to schedule.<br><br></div>In any case, as discussed in the meeting, this is an optimisation and not something we have to solve in the initial release, because:<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><br>
</div>Irena brought up the idea of using host aggregate. This requires creation of a non-SRIOV host aggregate, and use that in the above 'nova boot' command. It should work.
<div><br></div></div></blockquote><div><br></div><div>So, while it's not the greatest solution, there's at least a way of achieving it right now.<br></div></div></div></div>