[<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