Bug 1766917

Summary: [RFE] _get_max_tap_queues does not make a distinction between vhostuser and tap
Product: Red Hat OpenStack Reporter: Fabrizio Soppelsa <fsoppels>
Component: openstack-novaAssignee: smooney
Status: CLOSED DUPLICATE QA Contact: OSP DFG:Compute <osp-dfg-compute>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 13.0 (Queens)CC: dasmith, eglynn, fbaudin, jhakimra, kchamart, sbauza, sgordon, smooney, vromanso
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-07 19:29:22 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:
Embargoed:

Description Fabrizio Soppelsa 2019-10-30 09:38:26 UTC
Description of problem:
In code here: https://opendev.org/openstack/nova/src/branch/stable/train/nova/virt/libvirt/vif.py#L207-L241 the number of tap queues is determined:

            driver = 'vhost'
            max_tap_queues = self._get_max_tap_queues()

The function _get_max_tap_queues() returns a number based on the major kernel version.

There is no real distinction between the type of ports (i.e. vhostuser), so also for fast datapath on kernel 3, 8 will be returned anyway. "When the domain XML is written for the guest, vhost_queues is used in the 'queues' argument in the driver. When this value is >8, it fails when attempting to create the tap interface." and fails to start the VM[1].

We have a customer looking into the possibility of having more than 8 queues on fast datapath on kernel 3 (RHOSP 13).


Version-Release number of selected component (if applicable):
RHOSP 13, 14, 15


Additional info:
May qualify as RFE or NOTABUG if this scenario (> 8 queues, fast datapath) has been tested by us already with different combinations.

[1] https://access.redhat.com/solutions/3227911

Comment 2 smooney 2019-11-07 19:29:22 UTC

*** This bug has been marked as a duplicate of bug 1714075 ***