Open Stack

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