Bug 1793867 - Remove Stochastic Fairness Queueing for network QoS
Summary: Remove Stochastic Fairness Queueing for network QoS
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: SuperVDSM
Version: 4.30.38
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ovirt-4.4.0
: ---
Assignee: Bell Levin
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-22 06:41 UTC by Germano Veit Michel
Modified: 2020-04-17 10:23 UTC (History)
4 users (show)

Fixed In Version: rhv-4.4.0-28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-16 10:36:49 UTC
oVirt Team: Network
Embargoed:
dholler: ovirt-4.4?
dholler: devel_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 106791 0 master MERGED net: Remove support for sfq 2020-04-16 10:28:35 UTC

Description Germano Veit Michel 2020-01-22 06:41:34 UTC
When doing git bisect on el7 kernels, without setting any specific version on compile, the kernel ends up as version "3.10.0+"

# uname -r
3.10.0+

vdsm-4.30.38-1.el7ev.x86_64 fails to start because of this, when trying to decide between using SFQ or FC_CODEL qdisc:

It's the only daemon that fails to start due to the unusual kernel version and it's a bit annoying when testing.

Jan 22 16:15:13 host2 daemonAdapter: Traceback (most recent call last):
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/share/vdsm/supervdsmd", line 26, in <module>
Jan 22 16:15:13 host2 daemonAdapter: supervdsm_server.main(sys.argv[1:])
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 294, in main
Jan 22 16:15:13 host2 daemonAdapter: module_name))
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
Jan 22 16:15:13 host2 daemonAdapter: __import__(name)
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_api/network.py", line 25, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network.api import (setSafeNetworkConfig, setupNetworks,
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 34, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network import netswitch
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch/__init__.py", line 23, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from . import configurator
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch/configurator.py", line 33, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from vdsm.network import ifacquire
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/ifacquire.py", line 31, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from .configurators import ifcfg
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/configurators/__init__.py", line 32, in <module>
Jan 22 16:15:13 host2 daemonAdapter: from . import qos
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib/python2.7/site-packages/vdsm/network/configurators/qos.py", line 33, in <module>
Jan 22 16:15:13 host2 daemonAdapter: _FAIR_QDISC_KIND = 'fq_codel' if (StrictVersion(os.uname()[2].split('-')[0]) >
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/distutils/version.py", line 40, in __init__
Jan 22 16:15:13 host2 daemonAdapter: self.parse(vstring)
Jan 22 16:15:13 host2 daemonAdapter: File "/usr/lib64/python2.7/distutils/version.py", line 107, in parse
Jan 22 16:15:13 host2 daemonAdapter: raise ValueError, "invalid version number '%s'" % vstring
Jan 22 16:15:13 host2 daemonAdapter: ValueError: invalid version number '3.10.0+'

Perhaps specifically check if the kernel has the qdisc compiled is both less strict and more reliable?

# grep FQ_CODEL /boot/config-3.10.0-1062.9.1.el7.x86_64
CONFIG_NET_SCH_FQ_CODEL=m

Comment 1 Germano Veit Michel 2020-01-22 06:41:54 UTC
And feel free to close the BZ if its not trivial to improve it, it's easy to workaround.

Comment 2 Dominik Holler 2020-02-05 19:23:14 UTC
I found no reason to keep the support for sfq. Let's remove sfq support.

Comment 5 Lukas Svaty 2020-04-16 10:36:49 UTC
Closing low severity bugs, based on QE capacity, if you would like to still verify this issue please reopen.


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