netdev - Re: [PATCH net-next 0/4] net_sched: sch_fq: add WRR scheduling and 3 bands

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA93jw6uXa_RBG=HUhJsOQds-njZMYB-1MpfCnTGYFzU7gEVzg@mail.gmail.com>
Date: Sun, 1 Oct 2023 08:10:55 -0700
From: Dave Taht <dave.taht@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Willem de Bruijn <willemb@...gle.com>, 
	Soheil Hassas Yeganeh <soheil@...gle.com>, Neal Cardwell <ncardwell@...gle.com>, 
	Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>, 
	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next 0/4] net_sched: sch_fq: add WRR scheduling and 3 bands

On Sun, Oct 1, 2023 at 7:51 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> As discussed in Netconf 2023 in Paris last week, this series adds
> to FQ the possibility of replacing pfifo_fast for most setups.
>
> FQ provides fairness among flows, but malicious applications
> can cause problems by using thousands of sockets.
>
> Having 3 bands like pfifo_fast can make sure that applications
> using high prio packets (eg AF4) can get guaranteed throughput
> even if thousands of low priority flows are competing.
>
> Added complexity in FQ does not matter in many cases when/if
> fastpath added in the prior series is used.
>
> Eric Dumazet (4):
>   net_sched: sch_fq: remove q->ktime_cache
>   net_sched: export pfifo_fast prio2band[]
>   net_sched: sch_fq: add 3 bands and WRR scheduling
>   net_sched: sch_fq: add TCA_FQ_WEIGHTS attribute
>
>  include/net/sch_generic.h      |   1 +
>  include/uapi/linux/pkt_sched.h |  14 +-
>  net/sched/sch_fq.c             | 263 ++++++++++++++++++++++++++-------
>  net/sched/sch_generic.c        |   9 +-
>  4 files changed, 226 insertions(+), 61 deletions(-)
>
> --
> 2.42.0.582.g8ccd20d70d-goog
>
>

While I am delighted to see this, my concern is about udp traffic. I
have not paid much attention to how that is treated in sch_fq in
recent years, it was, originally, a second class citizen. I assume the
prio stuff here works on all protocols? Have similar pacing,
udp_notsent_lowat, etc things been added to that? (I really don´t
know,
I am lagging 4 years behind on kernel developments)

If that is not the case I would like the commit message clarified to
say something like "most tcp-mainly servers and clients, and not
routers, or applications leveraging udp without backpressure, such as
vpns, or voip, or quic applications. ¨ The confusion over the use
cases for sch_fq vs fq_codel or cake has been a PITA. I was very
pleased to see effective backpressure working on containers (circa
6.1)

Acked-By: Dave Taht <dave.taht@...il.com>

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos