Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #66870 > unrolled thread

Bug#890343: linux: make fq_codel default for default_qdisc

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#890343: linux: make fq_codel default for default_qdisc Matt Taggart <taggart@debian.org> - 2020-04-24 00:40 +0200
    Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2020-04-24 01:30 +0200
      Bug#890343: linux: make fq_codel default for default_qdisc Matt Taggart <taggart@debian.org> - 2020-04-24 07:10 +0200
    Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2021-01-08 01:20 +0100
      Bug#890343: linux: make fq_codel default for default_qdisc Ivan Baldo <ibaldo@adinet.com.uy> - 2021-01-18 02:40 +0100
        Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2021-01-20 23:00 +0100
      Bug#890343: linux: make fq_codel default for default_qdisc Vincent Blut <vincent.debian@free.fr> - 2021-01-20 22:30 +0100
        Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2021-01-20 23:10 +0100
          Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2021-01-20 23:30 +0100
            Processed: Re: Bug#890343: linux: make fq_codel default for  default_qdisc "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-01-20 23:30 +0100
          Bug#890343: linux: make fq_codel default for default_qdisc Vincent Blut <vincent.debian@free.fr> - 2021-01-20 23:50 +0100
            Bug#890343: linux: make fq_codel default for default_qdisc Noah Meyerhans <noahm@debian.org> - 2021-01-21 00:00 +0100
              Bug#890343: linux: make fq_codel default for default_qdisc Vincent Blut <vincent.debian@free.fr> - 2021-01-21 00:10 +0100
              Bug#890343: linux: make fq_codel default for default_qdisc Ben Hutchings <ben@decadent.org.uk> - 2021-01-21 00:50 +0100
                Bug#890343: linux: make fq_codel default for default_qdisc Vincent Blut <vincent.debian@free.fr> - 2021-02-26 19:10 +0100

#66870 — 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
taggart@debian.org

[toc] | [next] | [standalone]

#66872

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

[toc] | [prev] | [next] | [standalone]

#66874

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
taggart@debian.org

[toc] | [prev] | [next] | [standalone]

#69088

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

[toc] | [prev] | [next] | [standalone]

#69168

     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: <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
>
-- 
Ivan Baldo - ibaldo@adinet.com.uy - http://ibaldo.codigolibre.net/
Freelance C++/PHP programmer and GNU/Linux systems administrator.
The sky is not the limit!

[toc] | [prev] | [next] | [standalone]

#69209

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

[toc] | [prev] | [next] | [standalone]

#69208

[Multipart message — attachments visible in raw view] — view raw

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: <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.

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

[toc] | [prev] | [next] | [standalone]

#69210

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

[toc] | [prev] | [next] | [standalone]

#69211

Control: tags -1 + patch

A proposed patch is at
https://salsa.debian.org/kernel-team/linux/-/merge_requests/309

[toc] | [prev] | [next] | [standalone]

#69212 — Processed: Re: Bug#890343: linux: make fq_codel default for default_qdisc

Processing control commands:

> tags -1 + patch
Bug #890343 [linux] systemd: Debian could use the fq_codel network queuing algorithm by default
Added tag(s) patch.

-- 
890343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890343
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#69213

[Multipart message — attachments visible in raw view] — view raw

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?

[toc] | [prev] | [next] | [standalone]

#69214

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

[toc] | [prev] | [next] | [standalone]

#69215

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#69216

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#69637

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web