[openstack-dev] [nova] PCI handling (including SR-IOV), Traits, Resource Providers and Placement API - how to proceed?

Maciej Kucia maciej at kucia.net
Mon Jun 26 09:59:46 UTC 2017


Hi,

I have recently spent some time digging in Nova PCI devices handling code.
I would like to propose some improvements:
https://review.openstack.org/#/c/474218/ (Extended PCI alias)
https://review.openstack.org/#/q/status:open+project:openstack/nova+topic:PCI


but

There is an ongoing work on Resource Providers, Traits and Placement:
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/resource-providers.html
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/resource-provider-traits.html
https://github.com/openstack/os-traits
https://docs.openstack.org/developer/nova/placement.html

I am willing to contribute some work to the PCI handling in Queens.
Given the scope of changes a new spec will be needed.

The current PCI code has some issues that would be nice to fix. Most
notably:
 - Broken single responsibility principle
   A lot of classes are doing more than the name would suggest
 - Files and classes naming is not consistent
 - Mixed SR-IOV and PCI code
 - PCI Pools provide no real performance advantage and add unnecessary
complexity

My questions:
 - I understand that Nova will remain handling low-level operations between
OpenStack and hypervisor driver.
   Is this correct?
 - Will the `placement service` take the responsibility of managing PCI
devices?
 - Shall the SR-IOV handling be done by Nova or `placement service` (in
such case Nova would manage SR-IOV as a regular PCI)?
 - Where to store PCI configuration?
   For example currently nova.conf PCI Whitelist is responsible for some
SR-IOV configuration.
   Shall it be stored somewhere alongside `SR-IOV` resource provider?

Thanks,
Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170626/55c0892b/attachment.html>


More information about the OpenStack-dev mailing list