于 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
