Bug#890343: linux: make fq_codel default for default_qdisc
On Fri, Feb 26, 2021 at 06:58:50PM +0100, Vincent Blut wrote: > > > I think the distinction is that the other packages that tweak sysctl > > > values don't claim to be doing so on behalf of the kernel team. If > > > the > > > kernel team is responsible for the values being set, then the > > > settings > > > should come from a package that the kernel team owns, not some other > > > package. > > > > Right, maybe in linux-base? Although that might annoy derivatives that > > want different defaults. > > > > procps is the wrong place, not just because it's out of our hands, but > > because systemd applies sysctl configuration now and procps is > > optional. > > Is there a definitive answer from the kernel team about how this should be > implemented? In the meantime, Noah sent [1]. I've rebased https://salsa.debian.org/kernel-team/linux/-/merge_requests/309 against the current 'master' kernel branch on Salsa. Basic test results are below. It'd be nice if the kernel team could have a look and give feedback on the approach or recommend an alternative one if this isn't the one they'd like to pursue. # before reboot: admin@ip-10-0-0-136:~$ /sbin/tc qdisc qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev ens5 root qdisc pfifo_fast 0: dev ens5 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: dev ens5 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-136:~$ sudo apt install ./linux-image-5.16.0-rc3-cloud-amd64-unsigned_5.16~rc3-1~exp2_amd64.deb Reading package lists... Done Building dependency tree... Done Reading state information... Done Note, selecting 'linux-image-5.16.0-rc3-cloud-amd64-unsigned' instead of './linux-image-5.16.0-rc3-cloud-amd64-unsigned_5.16~rc3-1~exp2_amd64.deb' The following additional packages will be installed: firmware-linux-free Suggested packages: linux-doc-5.16 debian-kernel-handbook grub-pc | grub-efi-amd64 | extlinux The following NEW packages will be installed: firmware-linux-free linux-image-5.16.0-rc3-cloud-amd64-unsigned ... admin@ip-10-0-0-136:~$ sudo reboot Connection to 18.236.97.48 closed by remote host. ... admin@ip-10-0-0-136:~$ uname -a Linux ip-10-0-0-136 5.16.0-rc3-cloud-amd64 #1 SMP PREEMPT Debian 5.16~rc3-1~exp2 (2021-12-01) x86_64 GNU/Linux admin@ip-10-0-0-136:~$ /sbin/tc qdisc qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev ens5 root qdisc fq_codel 0: dev ens5 parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: dev ens5 parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
Bug#890343: linux: make fq_codel default for default_qdisc
Hi, Le 2021-01-21 00:43, Ben Hutchings a écrit : > On Wed, 2021-01-20 at 14:46 -0800, Noah Meyerhans wrote: > > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > > We could do that. However, in the past (earlier in this bug, > > > > even) it's > > > > been pointed out that other packages should not be responsible > > > > for > > > > setting kernel policies, so changes like this should be the > > > > responsibility of the kernel packages. That seems like a > > > > sensible > > > > position to take. > > > > > > If this is the position of the kernel team, then fine. But some > > > packages *do* > > > tweak kernel parameters using the sysctl interface mechanism. So > > > does the kernel > > > team provides documention about what is acceptable? > > > > I think the distinction is that the other packages that tweak sysctl > > values don't claim to be doing so on behalf of the kernel team. If > > the > > kernel team is responsible for the values being set, then the > > settings > > should come from a package that the kernel team owns, not some other > > package. > > Right, maybe in linux-base? Although that might annoy derivatives that > want different defaults. > > procps is the wrong place, not just because it's out of our hands, but > because systemd applies sysctl configuration now and procps is > optional. Is there a definitive answer from the kernel team about how this should be implemented? In the meantime, Noah sent [1]. > Ben. Cheers, Vincent [1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/309/diffs signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, 2021-01-20 at 14:46 -0800, Noah Meyerhans wrote: > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > We could do that. However, in the past (earlier in this bug, > > > even) it's > > > been pointed out that other packages should not be responsible > > > for > > > setting kernel policies, so changes like this should be the > > > responsibility of the kernel packages. That seems like a > > > sensible > > > position to take. > > > > If this is the position of the kernel team, then fine. But some > > packages *do* > > tweak kernel parameters using the sysctl interface mechanism. So > > does the kernel > > team provides documention about what is acceptable? > > I think the distinction is that the other packages that tweak sysctl > values don't claim to be doing so on behalf of the kernel team. If > the > kernel team is responsible for the values being set, then the > settings > should come from a package that the kernel team owns, not some other > package. Right, maybe in linux-base? Although that might annoy derivatives that want different defaults. procps is the wrong place, not just because it's out of our hands, but because systemd applies sysctl configuration now and procps is optional. Ben. > AFAIK, there are no guidelines or policy anywhere in Debian about > whether or not a package can provide its own sysctl settings. > > noah > -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#890343: linux: make fq_codel default for default_qdisc
Le 2021-01-20 14:46, Noah Meyerhans a écrit : > On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > > We could do that. However, in the past (earlier in this bug, even) it's > > > been pointed out that other packages should not be responsible for > > > setting kernel policies, so changes like this should be the > > > responsibility of the kernel packages. That seems like a sensible > > > position to take. > > > > If this is the position of the kernel team, then fine. But some packages > > *do* > > tweak kernel parameters using the sysctl interface mechanism. So does the > > kernel > > team provides documention about what is acceptable? > > I think the distinction is that the other packages that tweak sysctl > values don't claim to be doing so on behalf of the kernel team. If the > kernel team is responsible for the values being set, then the settings > should come from a package that the kernel team owns, not some other > package. Makes sense! > AFAIK, there are no guidelines or policy anywhere in Debian about > whether or not a package can provide its own sysctl settings. That would be nice to have a statement on this, though. > noah Cheers, Vincent signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, Jan 20, 2021 at 11:39:16PM +0100, Vincent Blut wrote: > > We could do that. However, in the past (earlier in this bug, even) it's > > been pointed out that other packages should not be responsible for > > setting kernel policies, so changes like this should be the > > responsibility of the kernel packages. That seems like a sensible > > position to take. > > If this is the position of the kernel team, then fine. But some packages *do* > tweak kernel parameters using the sysctl interface mechanism. So does the > kernel > team provides documention about what is acceptable? I think the distinction is that the other packages that tweak sysctl values don't claim to be doing so on behalf of the kernel team. If the kernel team is responsible for the values being set, then the settings should come from a package that the kernel team owns, not some other package. AFAIK, there are no guidelines or policy anywhere in Debian about whether or not a package can provide its own sysctl settings. noah
Bug#890343: linux: make fq_codel default for default_qdisc
Le 2021-01-20 13:58, Noah Meyerhans a écrit : > On Wed, Jan 20, 2021 at 10:22:16PM +0100, Vincent Blut wrote: > > My proposal would differ from yours though in that it would not touch the > > kernel > > configuration but would instead consist in patching procps to provide a > > configuration file (let's say default_qdisc.conf) to set the value of the > > net.core.default_qdisc variable to fq_codel via sysctl. > > This would allow to benefit from FQ_Codel without depending on a specific > > Linux > > version. > > We could do that. However, in the past (earlier in this bug, even) it's > been pointed out that other packages should not be responsible for > setting kernel policies, so changes like this should be the > responsibility of the kernel packages. That seems like a sensible > position to take. If this is the position of the kernel team, then fine. But some packages *do* tweak kernel parameters using the sysctl interface mechanism. So does the kernel team provides documention about what is acceptable? signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
Control: tags -1 + patch A proposed patch is at https://salsa.debian.org/kernel-team/linux/-/merge_requests/309
Bug#890343: linux: make fq_codel default for default_qdisc
On Wed, Jan 20, 2021 at 10:22:16PM +0100, Vincent Blut wrote: > My proposal would differ from yours though in that it would not touch the > kernel > configuration but would instead consist in patching procps to provide a > configuration file (let's say default_qdisc.conf) to set the value of the > net.core.default_qdisc variable to fq_codel via sysctl. > This would allow to benefit from FQ_Codel without depending on a specific > Linux > version. We could do that. However, in the past (earlier in this bug, even) it's been pointed out that other packages should not be responsible for setting kernel policies, so changes like this should be the responsibility of the kernel packages. That seems like a sensible position to take. One possible way for the kernel team to take ownership of this would be for it to introduce a new "debian-kernel-sysctl" package or something like that to provide some sysctl.d drop-in files. It could then set net.core.default_qdisc, and potentially others in various scenarios. Such a package can be installed indepdendently of whether the user is running a Debian-provided kernel package. The other alternative is the one I've proposed, which involves changing the compile-time defaults in Debian's kernel packages. This obviously only affects users of those packages. However, I think that's fine; people who are building their own packages may very well be starting from Debian's config, in which case they'll still get this change, or may be constructing their own configuration from scratch, in which case they're assuming ownership of all the parameters. noah
Bug#890343: linux: make fq_codel default for default_qdisc
On Sun, Jan 17, 2021 at 10:29:44PM -0300, Ivan Baldo wrote: > I think we want the mq qdisc to distribute the load between cores, to > support very high speed network cards or too slow CPUs. Yep, you're right. Though it's not about CPU cores, but about tx queues on the NIC hardware. > Also, if net.core.default_qdisc = fq_codel is used, it also has the mq > qdisc and fq_codel childs for each CPU core, so that's the default behavior > in other distros. Yep, so I think the behavior when we set the default qdisc to fq_codel in the kernel config has the effect we're looking for, after all. noah
Bug#890343: linux: make fq_codel default for default_qdisc
Hi Noah, Le 2021-01-07 16:12, Noah Meyerhans a écrit : > 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: 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: 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: 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. I was about to start a thread on the debian-kernel ML about switching from pfifo_fast to FQ_Codel when I stumble across this bug report. My proposal would differ from yours though in that it would not touch the kernel configuration but would instead consist in patching procps to provide a configuration file (let's say default_qdisc.conf) to set the value of the net.core.default_qdisc variable to fq_codel via sysctl. This would allow to benefit from FQ_Codel without depending on a specific Linux version. Opinion? > noah Cheers, Vincent signature.asc Description: PGP signature
Bug#890343: linux: make fq_codel default for default_qdisc
Hello. Not an expert nor kernel developer, etc., just simple sysadmin here, but will answer anyway since nobody did yet. I think we want the mq qdisc to distribute the load between cores, to support very high speed network cards or too slow CPUs. Also, if net.core.default_qdisc = fq_codel is used, it also has the mq qdisc and fq_codel childs for each CPU core, so that's the default behavior in other distros. I guess being under mq it could impact fq_codel's ability somewhat, but it's better to support all the hardware spectrum by default, otherwise we should use cake as default since it can handle up to 10Gbit/s without troubles; we don't, because Debian is a generic operating system so it should work on embedded devices, laptops, workstations and big iron servers... Also, I don't see a problem with statically linking fq_codel if we are using it as default, since it will probably get loaded anyway... Thanks for pushing this forward, doing these tests, etc.!!! Bye. El 7/1/21 a las 21:12, Noah Meyerhans escribió: 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: 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: 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: 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 -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ Freelance C++/PHP programmer and GNU/Linux systems administrator. The sky is not the limit!
Bug#890343: linux: make fq_codel default for default_qdisc
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: 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: 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: 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
Bug#890343: linux: make fq_codel default for default_qdisc
On 4/23/20 4:24 PM, Noah Meyerhans wrote: On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote: 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) Isn't CAKE supposed to be even better than fq_codel, including better handling of both large numbers of flows (e.g. busy routers) and small systems with limited resources. https://www.bufferbloat.net/projects/codel/wiki/Cake/ If we consider a change (which I think we should), is there a reason we wouldn't go with CAKE? In net/sched/Kconfig, the options for NET_SCH_DEFAULT are: fq, codel, fq_codel, sfq, pfifo_fast Also Documentation/admin-guide/sysctl/net.rst explains: default_qdisc - The default queuing discipline to use for network devices. This allows overriding the default of pfifo_fast with an alternative. Since the default queuing discipline is created without additional parameters so is best suited to queuing disciplines that work well without configuration like stochastic fair queue (sfq), CoDel (codel) or fair queue CoDel (fq_codel). Don't use queuing disciplines like Hierarchical Token Bucket or Deficit Round Robin which require setting up classes and bandwidths. Note that physical multiqueue interfaces still use mq as root qdisc, which in turn uses this default for its leaves. Virtual devices (like e.g. lo or veth) ignore this setting and instead default to noqueue. CAKE, while better for AQM, requires interface specific parameters and so won't work for a default (and also is generally used in conjunction with fq_codel) -- Matt Taggart tagg...@debian.org
Bug#890343: linux: make fq_codel default for default_qdisc
On Thu, Apr 23, 2020 at 03:34:06PM -0700, Matt Taggart wrote: > 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) Isn't CAKE supposed to be even better than fq_codel, including better handling of both large numbers of flows (e.g. busy routers) and small systems with limited resources. https://www.bufferbloat.net/projects/codel/wiki/Cake/ If we consider a change (which I think we should), is there a reason we wouldn't go with CAKE? noah
Bug#890343: linux: make fq_codel default for default_qdisc
#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? Related thoughts: * ubuntu issue, looks like maybe they already switched by default due to the systemd change? https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1773157 * another ubuntu issue that might help https://bugs.launchpad.net/ubuntu/+bug/940541 * are there other related defaults that should change too? like tcp_ecn, syncookies, BBR, etc * what are upstream kernel defaults and why? -- Matt Taggart tagg...@debian.org
