Open Stack

Hi Yongli,

Thank you for addressing my comments, and for adding the encryption card
use case. One thing that I want to point out is that in this use case, you
may not use the pci-flavor in the --nic option because it's not a neutron
feature.

I have a few more questions:
1. pci-flavor-attrs is configured through configuration files and will be
available on both the controller node and the compute nodes. Can the cloud
admin decide to add a new attribute in a running cloud? If that's
possible, how is that done?
2. PCI flavor will be defined using the attributes in pci-flavor-attrs. A
flavor is defined with a matching expression in the form of attr1 = val11
[| val12 Š.], [attr2 = val21 [| val22 Š]], Š. And this expression is used
to match one or more PCI stats groups until a free PCI device is located.
In this case, both attr1 and attr2 can have multiple values, and both
attributes need to be satisfied. Please confirm this understanding is
correct
3. I'd like to see an example that involves multiple attributes. let's say
pci-flavor-attrs = {gpu, net-group, device_id, product_id}. I'd like to
know how PCI stats groups are formed on compute nodes based on that, and
how many of PCI stats groups are there? What's the reasonable guidelines
in defining the PCI flavors.


thanks,
Robert



On 1/28/14 10:16 PM, "Robert Li (baoli)" <baoli at cisco.com> wrote:

>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
>>
>