Missing vNIC type for SR-IOV physical functions

Bug #1500993 reported by Miguel Angel Ajo on 2015-09-29
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Brent Eagles

Bug Description

One of the telco working group requirements is being able to expose a whole PF (physical function) on an SR-IOV card.

To indicate that to nova, we need to specify we want a "physicalfunction" type of port.

It's different from the ironic baremetal ports in the sense that those PFs will be memory mapped to the guest.

nova spec: https://review.openstack.org/#/c/212472/

description: updated
Changed in neutron:
assignee: nobody → Miguel Angel Ajo (mangelajo)
status: New → Confirmed
Miguel Angel Ajo (mangelajo) wrote :

Not sure why did I set this rfe to Confirmed, moving back to New.

Changed in neutron:
status: Confirmed → New
Changed in neutron:
assignee: Miguel Angel Ajo (mangelajo) → Brent Eagles (beagles)

Fix proposed to branch: master
Review: https://review.openstack.org/246923

Changed in neutron:
status: New → In Progress
Brent Eagles (beagles) on 2015-11-20
Changed in neutron:
status: In Progress → New
Changed in neutron:
status: New → In Progress
Brent Eagles (beagles) on 2015-11-23
Changed in neutron:
status: In Progress → New

Looks straightforward and the effort has momentum.

summary: - Define a new vNIC type for exposing complete physical functions (SR-IOV)
+ [RFE] Add vNIC type for SR-IOV physical functions
Henry Gessau (gessau) wrote :

Code already proposed, so this does not need to be an RFE.
See http://docs.openstack.org/developer/neutron/policies/blueprints.html

summary: - [RFE] Add vNIC type for SR-IOV physical functions
+ Missing vNIC type for SR-IOV physical functions
tags: removed: rfe
Changed in neutron:
importance: Undecided → Wishlist
status: New → In Progress
tags: added: sriov-pci-pt
Brent Eagles (beagles) wrote :

Some context for this proposed change is probably worthwhile. In addition to the nova spec mentioned in the bug description there is another related nova spec, https://review.openstack.org/#/c/212472/8 "Enable passthrough of SR-IOV physical functions to instances", that has already merged. Adding a VNIC type to enable creating and binding ports for physical functions is a fundamental step for Neutron to support the functionality mentioned in these two specifications.

With respect to cross-project dependency, neutron can safely implement and test the mechanics of this feature up to the point short of supporting an actual guest in nova. The nova changes are still ongoing, but this change can (and actually needs to) be implemented beforehand.

The python-neutronclient will also need a change to allow creating ports of this particular type. There is a patch currently in progress here:
https://review.openstack.org/#/c/246586/

Reviewed: https://review.openstack.org/246923
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2c60278992d5a217241054444ed0ca6e1d2f3e5c
Submitter: Jenkins
Branch: master

commit 2c60278992d5a217241054444ed0ca6e1d2f3e5c
Author: Brent Eagles <email address hidden>
Date: Mon Nov 9 09:26:53 2015 -0330

    Adding a VNIC type for physical functions

    This change adds a new VNIC type to distinguish between virtual and
    physical functions in SR-IOV.

    The new VNIC type 'direct-physical' deviates from the behavior of
    'direct' VNICs for virtual functions. While neutron tracks the resource
    as a port, it does not currently perform any management functions.
    Future changes may extend the segment mapping functionality that is
    currently based on agent configuration to include direct types.
    However, the direct-physical VNICs will not have functional parity with
    the other SR-IOV VNIC types in that quality of service and port security
    functionality is not available.

    APIImpact
    DocImpact: Add description for new 'direct-physical' VNIC type.

    Closes-Bug: #1500993

    Change-Id: If1ab969c2002c649a3d51635ca2765c262e2d37f

Changed in neutron:
status: In Progress → Fix Released

This issue was fixed in the openstack/neutron 8.0.0.0b2 development milestone.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers