On Tue, 2014-03-25 at 14:21 +0800, yongli he wrote:
> 于 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.
Hi Yongli,
I'm all for enabling users to take advantage of technology. I just will
push to make sure that the public user-facing API hides things like
vendor or product information as much as possible.
Best,
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
