Open Stack

于 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.
Jay

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

anyway, even without the product/vendor id, the multiple extra tag still 
needed.
and consideration this case, some accelerate card for encryption and 
decryption/hash
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
>
>