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
| ||
|
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
Powered by blists - more mailing lists