Hi, I added a few comments in this wiki that Yongli came up with: https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support
Please check it out and look for Robert in the wiki. Thanks, Robert On 1/21/14 9:55 AM, "Robert Li (baoli)" <ba...@cisco.com> wrote: >Yunhong, > >Just try to understand your use case: > -- a VM can only work with cards from vendor V1 > -- a VM can work with cards from both vendor V1 and V2 > > So stats in the two flavors will overlap in the PCI flavor solution. >I'm just trying to say that this is something that needs to be properly >addressed. > > >Just for the sake of discussion, another solution to meeting the above >requirement is able to say in the nova flavor's extra-spec > > encrypt_card = card from vendor V1 OR encrypt_card = card from >vendor V2 > > >In other words, this can be solved in the nova flavor, rather than >introducing a new flavor. > >Thanks, >Robert > > >On 1/17/14 7:03 PM, "yunhong jiang" <yunhong.ji...@linux.intel.com> wrote: > >>On Fri, 2014-01-17 at 22:30 +0000, Robert Li (baoli) wrote: >>> Yunhong, >>> >>> I'm hoping that these comments can be directly addressed: >>> a practical deployment scenario that requires arbitrary >>> attributes. >> >>I'm just strongly against to support only one attributes (your PCI >>group) for scheduling and management, that's really TOO limited. >> >>A simple scenario is, I have 3 encryption card: >> Card 1 (vendor_id is V1, device_id =0xa) >> card 2(vendor_id is V1, device_id=0xb) >> card 3(vendor_id is V2, device_id=0xb) >> >> I have two images. One image only support Card 1 and another image >>support Card 1/3 (or any other combination of the 3 card type). I don't >>only one attributes will meet such requirement. >> >>As to arbitrary attributes or limited list of attributes, my opinion is, >>as there are so many type of PCI devices and so many potential of PCI >>devices usage, support arbitrary attributes will make our effort more >>flexible, if we can push the implementation into the tree. >> >>> detailed design on the following (that also take into account >>> the >>> introduction of predefined attributes): >>> * PCI stats report since the scheduler is stats based >> >>I don't think there are much difference with current implementation. >> >>> * the scheduler in support of PCI flavors with arbitrary >>> attributes and potential overlapping. >> >>As Ian said, we need make sure the pci_stats and the PCI flavor have the >>same set of attributes, so I don't think there are much difference with >>current implementation. >> >>> networking requirements to support multiple provider >>> nets/physical >>> nets >> >>Can't the extra info resolve this issue? Can you elaborate the issue? >> >>Thanks >>--jyh >>> >>> I guess that the above will become clear as the discussion goes on. >>> And we >>> also need to define the deliveries >>> >>> Thanks, >>> Robert >> >> >>_______________________________________________ >>OpenStack-dev mailing list >>OpenStack-dev@lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
