Hi Folks,
In light of today's IRC meeting, and for the purpose of moving this forward,
I'm fine to go with the following if that's what everyone wants to go with:
https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit
But with some concerns and reservations.
--- I don't expect everyone to agree on this. But I think the proposal is
much more complicated in terms of implementation and administration.
--- I'd like to see a practical deployment scenario in which only PCI flavor
can support, but PCI group can't, which I guess can justify the complexities.
--- do we agree that BDF address (or device id, whatever you call it), and
node id shouldn't be used as attributes in defining a PCI flavor?
--- I'd like to see a detailed (not vague) design on the following:
* PCI stats report since the scheduler is stats based
* the scheduler in support of PCI flavors with arbitrary attributes.
--- I'd like to see how this can be mapped into SRIOV support:
* the compute node needs to know the PCI flavor. A couple of reasons
for this:
- the neutron plugin may need this to associate with a
particular subsystem (or physical network)
- to support live migration, we need to use it to create
network xml
* We also need to be able to do auto discovery so that we can support
live migration with SRIOV
* use the PCI flavor in the —nic option and neutron commands
--- Just want to point out that this PCI flavor doesn't seem to be the same
PCI flavor that Join was talking about in one of his emails.
I'd like to also point out that if you consider a PCI group as an attribute (in
terms of the proposal), then the PCI group design is a special (or degenerated)
case of the proposed design. The significant difference here is that with PCI
group, its semantics is clear and well defined, and everything else works on
top of it. An attribute is arbitrary and open for interpretation. In terms of
getting things done ASAP, the PCI group is actually the way to go.
I guess that we will take a phased approach to implement it so that we can get
something done in Icehouse. However, I'd like to see that neutron requirements
one way or the other can be satisfied in the first phase.
Maybe we can continue the IRC tomorrow and talk about the above. Again, let's
move on if that's really where we want to go.
thanks,
Robert
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
