Bug 1325686

Summary: [RFE] [Neutron] Manage SR-IOV PFs as Neutron ports
Product: Red Hat OpenStack Reporter: Nir Yechiel <nyechiel>
Component: openstack-neutronAssignee: Brent Eagles <beagles>
Status: CLOSED ERRATA QA Contact: Eran Kuris <ekuris>
Severity: high Docs Contact:
Priority: high    
Version: 9.0 (Mitaka)CC: amuller, beagles, chrisw, jschluet, nyechiel, oblaut, sclewis, smerrow, srevivo
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: openstack-neutron-8.1.1-0.20160602163729.96a195c.el7ost Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-14 15:32:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1233906, 1367263, 1367790, 1371856    
Bug Blocks: 1458798, 1378689    

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. 


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


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:

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
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] . 



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.