Bug 1325686 - [RFE] [Neutron] Manage SR-IOV PFs as Neutron ports
Summary: [RFE] [Neutron] Manage SR-IOV PFs as Neutron ports
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 9.0 (Mitaka)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 10.0 (Newton)
Assignee: Brent Eagles
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On: 1233906 1367263 1367790 1371856
Blocks: 1458798 1378689
TreeView+ depends on / blocked
 
Reported: 2016-04-10 16:43 UTC by Nir Yechiel
Modified: 2017-07-31 14:06 UTC (History)
9 users (show)

Fixed In Version: openstack-neutron-8.1.1-0.20160602163729.96a195c.el7ost
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-14 15:32:50 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:2948 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 enhancement update 2016-12-14 19:55:27 UTC
OpenStack gerrit 239875 None None None 2016-04-10 16:49:11 UTC
OpenStack gerrit 246923 None None None 2016-04-10 16:50:47 UTC
OpenStack gerrit 262604 None None None 2016-04-10 16:50:04 UTC
Red Hat Bugzilla 1367786 None CLOSED [RFE] SRIOV - PF / VM that assign to PF does not get vlan tag 2019-09-05 08:51:57 UTC
Red Hat Bugzilla 1367790 None CLOSED SRIOV- To assign neutron port to PF we need to set in whitelist the PCI ID 2019-09-05 08:51:57 UTC
Red Hat Bugzilla 1370047 None CLOSED Cant revert from neutron-port PF to VF because sriov_numvfs parameter get "0" value 2019-09-05 08:51:57 UTC
Launchpad 1608176 None None None 2016-08-16 08:42:05 UTC
Launchpad 1614086 None None None 2016-08-17 13:08:10 UTC

Description Nir Yechiel 2016-04-10 16:43:40 UTC
Description of problem:

Current implementation of the Physical Function (PF) passthrough lacks
any network awareness. It is exposing the physical hardware to the instances
without an integration with Neutron, unlike the way it is implemented for the
SR-IOV Virtual Functions (VFs). Workloads requiring to have full access to a physical function will also need to have the ability to manipulate the network settings, in the same manner and flexibility that is currently available for VFs.

Comment 3 Assaf Muller 2016-06-04 20:08:03 UTC
Can you please fill in the doctext? Thank you.

Comment 7 Jon Schlueter 2016-06-08 11:13:19 UTC
resetting Fixed in version to osp 9 build

Comment 13 Eran Kuris 2016-08-09 11:23:12 UTC
Hi Brent , 
please take a look on this test plan ,  
I would like get your comments before I start to run the tests . If you think I need to add / remove something please let me know. 

https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/workitem?id=RHELOSP-15921

Also I would to know how can I check the PF attached to instance?
should I see it in : ip link show ?  

thanks

Comment 15 Eran Kuris 2016-08-17 13:20:09 UTC
After I check the RFE  I found few bugs . I attached all relevant bugs and assign it to DEV .

Comment 16 Brent Eagles 2016-08-29 13:23:51 UTC
With respect to blockers for this RFE, I suggest that:

Configuring system so that PFs work:
https://bugzilla.redhat.com/show_bug.cgi?id=1367790
https://bugzilla.redhat.com/show_bug.cgi?id=1367263
https://bugzilla.redhat.com/show_bug.cgi?id=1369768

I believe there is some overlap. In general the documented mechanisms for configuring PFs have issues. It can be said that there is a workaround because as long as you configure things a specific way, things will work. Unfortunately, the syntax that does work might end up including PCI devices that an administrator doesn't want used. That is, the working syntax isn't specific enough. The other aspect is that there may be issues with the SR-IOV agent when a PF is allocated as the VFs "disappear". I don't think it crashes, but of any issue referenced, this one gives the me the most pause. In short, I don't think these are really blockers, but as a group

VLAN-id https://bugzilla.redhat.com/show_bug.cgi?id=1367786
IIUC this was not a use case covered by the intended scope of the current implementation. So this is more of an additional feature/functionality than a blocker

Setting numvfs to 0
https://bugzilla.redhat.com/show_bug.cgi?id=1370047
This is basically the SR-IOV agent being configured to monitor something that we are removing the VFs from but leaving the bare interface there. FWICT, we don't need to, and should not, be setting numvfs to 0. If we intend something to be used as PF only, the SR-IOV agent should not be configured to monitor it.

In summary, we have a working "recipe" for using PFs that works under certain conditions. The reported bugs cover the "negative ground". The core functionality works, but with known issues and limitations. As such, we should consider removing these as a blocker contingent on appropriate documentation of the aforementioned issues.

Comment 22 Eran Kuris 2016-11-03 07:10:49 UTC
verified on OSPD10 puddle 2016-10-06.1  its looks ok except the bugs that already opened and attached in this bug [depends on] . 

https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/testrun?id=OSP-10-SRIOV-PF


https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/testrun?id=NFV%2D001

Comment 24 errata-xmlrpc 2016-12-14 15:32:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2948.html


Note You need to log in before you can comment on or make changes to this bug.