Open Stack

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)" <baoli at 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.jiang at 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 at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>