PCI passthrough: extra info/flavor enhancement

Registered by jiang, yunhong

PCI devices has not only PCI standard property like BDF, vendor_id etc, it also has some extra information which may be application specific. For example, attached network switch for NIC, or resolution for GPU etc.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Yongli He
Direction:
Needs approval
Assignee:
Yongli He
Definition:
Review
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

I am ducking out of the review for this if possible, there is more agreement now I think, but I have spend too many hours trying to review this. Parting thoughts:
* PCI flavor seems like a good user facing concept
* NICs having extra info the suggests a PCI flavor makes sense too
* the host details should store the mapping of what PCI flavors are available
* main worry for me is how to persist the PCI flavor info, I recon host-aggregates would work - but need to see what extra db tables would be better
-- johnthetubagy

johnthetubaguy,
all requement comments is address, bp also merged. -- yongli He

use case updated to
https://wiki.openstack.org/wiki/PCI_configration_Database_and_API#API_for_whitelist
--yonglihe

It is hard to review this without seeing the API implemented. We generally don't like to accept code that is not used or exposed, and each checkin should leave nova working. I am not sure I quite understand the split between this blueprint and the blueprint below. vote we combine them.
--johnthetubaguy

discuss about use caseļ¼š
https://docs.google.com/document/d/1EMwDg9J8zOxzvTnQJ9HwZdiotaVstFWKIuKrPse6JOs/edit?pli=1#heading=h.30de7p6sgoxp

This is targeted for icehouse but all the reviews below are extremely preliminary and all have been auto-abandoned. Should this still be targeted for I2? I'm not sure I'd approve this for I2 unless things are farther along than they appear to be. --dansmith

hi, dansmith
all because some design consideration is not resloved yet, but we are work hard on it. --yonglihe

Gerrit topic: https://review.openstack.org/#q,topic:PCI-passthrough-next-step,n,z

Addressed by: https://review.openstack.org/57859
    PCI base group support

Addressed by: https://review.openstack.org/57860
    PCI whitelist support group with by PCI address

Addressed by: https://review.openstack.org/57861
    PCI reqeust support group

Gerrit topic: https://review.openstack.org/#q,topic:bp/pci-extra-info,n,z

Addressed by: https://review.openstack.org/63267
    PCI stats group on demand

Addressed by: https://review.openstack.org/63268
    PCI allocation marking

Addressed by: https://review.openstack.org/61692
    Fix init of pci_stats in resource tracker

Addressed by: https://review.openstack.org/64796
    PCI config database support

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Addressed by: https://review.openstack.org/74632
    pci request mark interface

Addressed by: https://review.openstack.org/74633
    Enhance PCI alias to support pci flavor attr

Realizing that I am going to seem like a broken record, but we need a plan for how this is going to be tested. e.g. how much can be done in tempest, how much reliance is there on third party testing for adequate coverage etc.. - beagles

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Gerrit topic: https://review.openstack.org/#q,topic:bp/for,n,z

Addressed by: https://review.openstack.org/87500
    proposed blueprint for PCI extra information support

Gerrit topic: https://review.openstack.org/#q,topic:pci-extra-info,n,z

(?)

Work Items