1

I am very interested in setting up fq_pie queue discipline for TCP congestion control. If I write net.core.default_qdisc = fq_pie to /etc/sysctl.d/90-override.conf, it should enable fq_pie on latest kernels.

It does work on my desktop though. But on my laptop:

$ tc qdisc show
qdisc noqueue 0: dev lo root refcnt 2 
qdisc noqueue 0: dev wlp1s0 root refcnt 2 
qdisc mq 0: dev wlp0s20f0u3 root 
qdisc fq_pie 0: dev wlp0s20f0u3 parent :4 limit 10240p flows 1024 target 15ms tupdate 16ms alpha 2 beta 20 quantum 1514b memory_limit 32Mb ecn_prob 10 
qdisc fq_pie 0: dev wlp0s20f0u3 parent :3 limit 10240p flows 1024 target 15ms tupdate 16ms alpha 2 beta 20 quantum 1514b memory_limit 32Mb ecn_prob 10 
qdisc fq_pie 0: dev wlp0s20f0u3 parent :2 limit 10240p flows 1024 target 15ms tupdate 16ms alpha 2 beta 20 quantum 1514b memory_limit 32Mb ecn_prob 10 
qdisc fq_pie 0: dev wlp0s20f0u3 parent :1 limit 10240p flows 1024 target 15ms tupdate 16ms alpha 2 beta 20 quantum 1514b memory_limit 32Mb ecn_prob 10

As it can be seen that I have 2 wifi adapters. One comes inbuilt to my laptop, which is Qualcomm Atheros (ath10k), fq_pie can't be activated on this.

The fq_pie however, can be activated on TP Link (RTL8188EUS) adapter.

I have also tried 2 more laptops (Dell and HP), the integrated wifi adapter is not actually running fq_pie.

Is there a way to forcefully activate fq_pie to the Qualcomm Atheros and other wifi adapters?

System Details:

$ cat /proc/version
Linux version 5.8.12-xanmod1-1 (makepkg@archlinux) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Wed, 30 Sep 2020 14:19:49 +0000

$ ip -V
ip utility, iproute2-v5.7.0-77-gb687d1067169

$ tc -V
tc utility, iproute2-v5.7.0-77-gb687d1067169
Improve this question

1 Answer 1

Reset to default
1

It appears net.core.default_qdisc affects an interface driver when it's loaded. If the kernel module was loaded before net.core.default_qdisc was changed, then it won't affect it afterward. Some interfaces have altered behaviour: multiqueue interfaces will keep mq but their leaves inherit this default instead. lo or veth won't get any default queue.

If you want to ensure the sysctl is changed before the driver, you could:

  • have it changed in initramfs scripts (some tweaking is probably needed),

  • have it loaded from kernel cmdline. This Q/A tells it's possible for any arbitrary sysctl only since kernel 5.8, which you are using. So in theory you could add something this in the boot parameters (probably in GRUB's GRUB_CMDLINE_LINUX) and forget about it:

    sysctl.net.core.default_qdisc=fq_pie

    but actually this is possible only for built-in drivers. It's very unlikely that sch_fq_pie was compiled built-in.

  • delay the loading of the driver for wlp1s0 (I wouldn't know where to do this)

  • rmmod ath10k and modprobe ath10k so the new default applies.

Anyway to immediately change an interface's qdisc, just define its qdisc, which will override the default kernel qdisc, which has the reserved handle 0:. For example:

tc qdisc add dev wlp1s0 handle 1: root fq_pie
Improve this answer
6
  • That's a very good suggestion. But even with the command line parameter, the fq_pie isn't applied. It's shown in the /proc/cmdline though. Also, rmmod ath10k_pci ath10k_core ath and modprobing them didn't help as well. That said, an external wifi adapter, when hotplugged, gets fq_pie applied to the interface. Commented Oct 19, 2020 at 6:17
  • Yup, after rmmodding and modprobing tc shows the wlan0 interface in the end, with noqueue: qdisc noqueue 0: dev wlp1s0 root refcnt 2 Commented Oct 19, 2020 at 7:10
  • 1
    Forget rmmod. The tc command alone should work in all cases. Nothing before is needed. This tc command has to be done again until there's not written 0: anymore. Commented Oct 19, 2020 at 7:14
  • 1
    rmmoding all ath modules didn't help, it disabled the wifi adapter as it should, that means it was successful. But I am not really getting why the sysctl rule isn't getting applied... I should probably make a systemd unit file with the tc command to apply it to boot... Commented Oct 19, 2020 at 7:27
  • 1
    I didn't read correctly the last comment. If you add the tc command, you should consider doing it as a plugin to the network service managing your interfaces. If done in systemd this should be done late, not early, to be sure the interface does exist. In all cases this command fails (harmlessly) if run a 2nd time so manage to either blindly tell ok or check if it was already done. Commented Oct 19, 2020 at 10:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.