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:
 <AM6PR07MB4456EAF742A691AD513AE8C1B9552@AM6PR07MB4456.eurprd07.prod.outlook.com>
Date: Thu, 31 Oct 2024 16:45:01 +0000
From: "Koen De Schepper (Nokia)" <koen.de_schepper@...ia-bell-labs.com>
To: Eric Dumazet <edumazet@...gle.com>, Neal Cardwell <ncardwell@...gle.com>
CC: Paolo Abeni <pabeni@...hat.com>, "Chia-Yu Chang (Nokia)"
	<chia-yu.chang@...ia-bell-labs.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>, "jhs@...atatu.com"
	<jhs@...atatu.com>, "kuba@...nel.org" <kuba@...nel.org>, "dsahern@...nel.org"
	<dsahern@...nel.org>, "ij@...nel.org" <ij@...nel.org>,
	"g.white@...lelabs.com" <g.white@...lelabs.com>,
	"ingemar.s.johansson@...csson.com" <ingemar.s.johansson@...csson.com>,
	"mirja.kuehlewind@...csson.com" <mirja.kuehlewind@...csson.com>,
	"cheshire@...le.com" <cheshire@...le.com>, "rs.ietf@....at" <rs.ietf@....at>,
	"Jason_Livingood@...cast.com" <Jason_Livingood@...cast.com>,
	"vidhi_goel@...le.com" <vidhi_goel@...le.com>, Olga Albisser
	<olga@...isser.org>, "Olivier Tilmans (Nokia)" <olivier.tilmans@...ia.com>,
	Henrik Steen <henrist@...rist.net>, Bob Briscoe <research@...briscoe.net>
Subject: RE: [PATCH v4 net-next 1/1] sched: Add dualpi2 qdisc


From: Eric Dumazet <edumazet@...gle.com> 
Sent: Thursday, October 31, 2024 3:31 PM
> On Thu, Oct 31, 2024 at 2:28 PM Neal Cardwell <ncardwell@...gle.com> wrote:
> > On Tue, Oct 29, 2024 at 12:53 PM Eric Dumazet <edumazet@...gle.com> wrote:
> > > Also, it seems this qdisc could be a mere sch_prio queue, with two 
> > > sch_pie children, or two sch_fq or sch_fq_codel ?
> >
> > Having two independent children would not allow meeting the dualpi2 
> > goal to "preserve fairness between ECN-capable and non-ECN-capable 
> > traffic." (quoting text from https://datatracker.ietf.org/doc/rfc9332/
> > ). The main issue is that there may be differing numbers of flows in 
> > the ECN-capable and non-ECN-capable queues, and yet dualpi2 wants to 
> > maintain approximate per-flow fairness on both sides. To do this, it 
> > uses a single qdisc with coupling of the ECN mark rate in the 
> > ECN-capable queue and drop rate in the non-ECN-capable queue.
>
> Not sure I understand this argument.
>
> The dequeue  seems to use WRR, so this means that instead of prio, this could use net/sched/sch_drr.c, then two PIE (with different settings) as children, and a proper classify at enqueue to choose one queue or the other.
>
> Reviewing ~1000 lines of code, knowing that in one year another net/sched/sch_fq_dualpi2.c will follow (as net/sched/sch_fq_pie.c followed net/sched/sch_pie.c ) is not exactly appealing to me.

This composition doesn't work. We need more than 2 independent AQMs and a scheduler. The coupling between the queues and other extra interworking conditions is very important here, which are unfortunately not possible with a composition of existing qdiscs.

Also, we don't expect any FQ and DualQ merger. Using only 2 queues (one for each class L4S and Classic) is one of the differentiating features of DualQ compared to FQ, with a lower L4S tail latency compared to a blocking and scheduled FQ qdiscs. Adding FQ_ on top or under DualQ would break the goal of DualQ. If an FQ_ supporting L4S is needed, then existing FQ_ implementations can be used (like fq_codel) or extended (identifying L4S and using the correct thresholds by default).

Regards,
Koen.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ