On Mon, 2014-01-27 at 14:58 +0000, Robert Li (baoli) wrote: > Hi Folks, > > > 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: > -- SRIOV only compute nodes > -- non-SRIOV only compute nodes > -- 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. > > > 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. > > > In a cloud that supports SRIOV in some of the compute nodes, a request > such as: > > > nova boot —flavor m1.large —image <image-uuid> --nic > net-id=<net-uuid> vm > > > doesn't require a SRIOV port. However, it's possible for the nova > scheduler to place it on a compute node that supports sriov port only. > Since neutron plugin runs on the controller, port-create would succeed > unless neutron knows the host doesn't support non-sriov port. But > connectivity on the node would not be established since no agent is > running on that host to establish such connectivity. > > > 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. > > > The patch I had introduced a new constraint in the existing PCI > passthrough filter. > > > The consensus seems to be having a better solution in a later release. > And for now, people can either use host aggregate or resort to their > own means. > > > Let's keep the discussion going on this. > > > Thanks, > Robert > > > > > > > > > > On 1/24/14 4:50 PM, "Robert Li (baoli)" <ba...@cisco.com> wrote: > > > Hi Folks, > > > Based on Thursday's discussion and a chat with Irena, I took > the liberty to add a summary and discussion points for SRIOV > on Monday and onwards. Check it > out https://wiki.openstack.org/wiki/Meetings/Passthrough. > Please feel free to update it. Let's try to finalize it next > week. The goal is to determine the BPs that need to get > approved, and to start coding. > > > thanks, > Robert > > > > > On 1/22/14 8:03 AM, "Robert Li (baoli)" <ba...@cisco.com> > wrote: > > > Sounds great! Let's do it on Thursday. > > > --Robert > > > On 1/22/14 12:46 AM, "Irena Berezovsky" > <ire...@mellanox.com> wrote: > > > Hi Robert, all, > > I would suggest not to delay the SR-IOV > discussion to the next week. > > Let’s try to cover the SRIOV side and > especially the nova-neutron interaction points > and interfaces this Thursday. > > Once we have the interaction points well > defined, we can run parallel patches to cover > the full story. > > > > Thanks a lot, > > Irena > > > > From: Robert Li (baoli) > [mailto:ba...@cisco.com] > Sent: Wednesday, January 22, 2014 12:02 AM > To: OpenStack Development Mailing List (not > for usage questions) > Subject: [openstack-dev] [nova][neutron] PCI > passthrough SRIOV > > > > > Hi Folks, > > > > > > As the debate about PCI flavor versus host > aggregate goes on, I'd like to move forward > with the SRIOV side of things in the same > time. I know that tomorrow's IRC will be > focusing on the BP review, and it may well > continue into Thursday. Therefore, let's start > discussing SRIOV side of things on Monday. > > > > > > Basically, we need to work out the details on: > > > -- regardless it's PCI flavor or host > aggregate or something else, how to use it to > specify a SRIOV port. > > > -- new parameters for —nic > > > -- new parameters for neutron > net-create/neutron port-create > > > -- interface between nova and neutron > > > -- nova side of work > > > -- neutron side of work > > > > > > We should start coding ASAP. > > > > > > Thanks, > > > Robert > > > > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I noticed that you discussed that prefer non-SRIOV compute node to SRIOV compute node. I think that should be achieved through weight? Thanks --jyh _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
