[openstack-dev] [nova] [neutron] PCI pass-through network support

Robert Li (baoli) baoli at cisco.com
Wed Jan 29 03:16:49 UTC 2014


I added a few comments in this wiki that Yongli came up with:

Please check it out and look for Robert in the wiki.


On 1/21/14 9:55 AM, "Robert Li (baoli)" <baoli at cisco.com> wrote:

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

More information about the OpenStack-dev mailing list