Bug#890343: linux: make fq_codel default for default_qdisc
- To: Matt Taggart <taggart@debian.org>, 890343@bugs.debian.org
- Subject: Bug#890343: linux: make fq_codel default for default_qdisc
- From: Noah Meyerhans <noahm@debian.org>
- Date: Thu, 7 Jan 2021 16:12:41 -0800
- Message-id: <X/ejedVaBdSPRHRB@doom.morgul.net>
- Reply-to: Noah Meyerhans <noahm@debian.org>, 890343@bugs.debian.org
- In-reply-to: <57291d92-ba62-17c7-ef72-3e359922c27b@debian.org>
- References: <b48d19da-0be2-f632-a1d3-efccd2f69f1f@laposte.net> <57291d92-ba62-17c7-ef72-3e359922c27b@debian.org> <b48d19da-0be2-f632-a1d3-efccd2f69f1f@laposte.net>
On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote:
> #890343 was originally opened against systemd asking to install the upstream
> systemd sysctl.d/50-default.conf file that sets:
>
> net.core.default_qdisc = fq_codel
>
> As explained in #950701 (and the systemd debian changelog) the debian
> systemd maintainers felt that systemd in debian should not be changing
> kernel policies (and I agree).
> So #890343 was reassigned to linux to consider changing the default.
>
> fq_codel is better in every way than pfifo_fast and I am unaware of any
> reason why it would not be a better default. (but don't trust me, ask the
> kernel networking experts)
>
> Can we change it?
I strongly agree that we should make this change for the bullseye
release.
I'm looking into provding a patch to implement the switch to fq_codel by
default, but it appears to require something more than just a kernel
config change. I have tried the following with the 5.10 kernel from the
current sid branch:
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
Then we don't see any change at all to the qdisc in use:
admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
CONFIG_NET_SCH_FQ_CODEL=m
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
net.core.default_qdisc = pfifo_fast
admin@ip-10-0-0-162:~$ tc qdisc show dev ens5
qdisc mq 0: root
qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5
If we statically link the fq_codel module into the kernel, then we see:
admin@ip-10-0-0-162:~$ grep -i fq_codel /boot/config-$(uname -r)
CONFIG_NET_SCH_FQ_CODEL=y
CONFIG_DEFAULT_FQ_CODEL=y
CONFIG_DEFAULT_NET_SCH="fq_codel"
admin@ip-10-0-0-162:~$ /sbin/sysctl net.core.default_qdisc
net.core.default_qdisc = fq_codel
admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
qdisc mq 0: root
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5
So in this case, we have fq_codel configured, but not as the root
qdisc for the interface. If we manually set it:
admin@ip-10-0-0-162:~$ sudo /sbin/tc qdisc add root dev ens5 fq_codel
Then we get the following configuration:
admin@ip-10-0-0-162:~$ /sbin/tc qdisc show dev ens5
qdisc fq_codel 8001: root refcnt 3 limit 10240p flows 1024 quantum 9015 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
admin@ip-10-0-0-162:~$ ip link show dev ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 02:47:e2:7c:be:ff brd ff:ff:ff:ff:ff:ff
altname enp0s5
I believe that this is what we want. Is that accurate?
The recent thread at https://www.mail-archive.com/netdev@vger.kernel.org/msg380410.html
also seems relevant.
noah
Reply to: