[openstack-dev] [nova][PCI] one use case make the flavor/extra-info based solution to be right choice

yongli he yongli.he at intel.com
Tue Mar 25 06:21:26 UTC 2014

于 2014年03月21日 03:18, Jay Pipes 写道:
> On Thu, 2014-03-20 at 13:50 +0000, Robert Li (baoli) wrote:
>> Hi Yongli,
>> I'm very glad that you bring this up and relive our discussion on PCI
>> passthrough and its application on networking. The use case you brought up
>> is:
>>             user wants a FASTER NIC from INTEL to join a virtual
>> networking.
>> By FASTER, I guess that you mean that the user is allowed to select a
>> particular vNIC card. Therefore, the above statement can be translated
>> into the following requests for a PCI device:
>>          . Intel vNIC
>>          . 1G or 10G or ?
>>          . network to join
>> First of all, I'm not sure in a cloud environment, a user would care about
>> the vendor or card type.
> Correct. Nor would/should a user of the cloud know what vendor or card
> type is in use on a particular compute node. At most, all a user of the
> cloud would be able to select from is an instance type (flavor) that
> listed some capability like "high_io_networking" or something like that,
> and the mapping of what "high_io_networking" meant on the back end of
> Nova would need to be done by the operator (i.e. if the tag
> "high_io_networking" is on a flavor a user has asked to launch a server
> with, then that tag should be translated into a set of capabilities that
> is passed to the scheduler and used to determine where the instance can
> be scheduled by looking at which compute nodes support that set of
> capabilities.
> This is what I've been babbling about with regards to "leaking
> implementation through the API". What happens if, say, the operator
> decides to use IBM cards (instead of or in addition to Intel ones)? If
> you couple the implementation with the API, like the example above shows
> ("user wants a FASTER NIC from INTEL"), then you have to add more
> complexity to the front-end API that a user deals with, instead of just
> adding a capabilities mapping for new compute nodes that says
> "high_io_networking" tag can match to these new compute nodes with IBM
> cards.

thank you, sorry for later reply

in this use case, use might so not care about the vendor id/product id.
but for a specific image , the product's model(which related to the 
vendor id/product id)
might cared by user. cause the image might could not support new device
which possibly use vendor_id and product id to eliminate the unsupported 

anyway, even without the product/vendor id, the multiple extra tag still 
and consideration this case, some accelerate card for encryption and 
there are many supported feature, and most likely different pci card 
might support
different feature set,like : md5, DES,3DES, AES, RSA, SHA-x, IDEA, 
RC4,5,6 ....
the way to select such a device is use it's feature set instead of one 
or 2 of group, so
the extra information about a pci card is need, in a flexible way.

Yongli He

> Best,
> -jay
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list