[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f880f49c2d9ef20ab087c6e9d1a6d6c8f6e500a.camel@fejes.dev>
Date: Tue, 24 Jun 2025 14:34:57 +0200
From: Ferenc Fejes <ferenc@...es.dev>
To: chia-yu.chang@...ia-bell-labs.com, alok.a.tiwari@...cle.com,
pctammela@...atatu.com, horms@...nel.org, donald.hunter@...il.com,
xandfury@...il.com, netdev@...r.kernel.org, dave.taht@...il.com,
pabeni@...hat.com, jhs@...atatu.com, kuba@...nel.org,
stephen@...workplumber.org, xiyou.wangcong@...il.com, jiri@...nulli.us,
davem@...emloft.net, edumazet@...gle.com, andrew+netdev@...n.ch,
ast@...erby.net, liuhangbin@...il.com, shuah@...nel.org,
linux-kselftest@...r.kernel.org, ij@...nel.org, ncardwell@...gle.com,
koen.de_schepper@...ia-bell-labs.com, g.white@...lelabs.com,
ingemar.s.johansson@...csson.com, mirja.kuehlewind@...csson.com,
cheshire@...le.com, rs.ietf@....at, Jason_Livingood@...cast.com,
vidhi_goel@...le.com
Subject: Re: [PATCH v20 net-next 0/6] DUALPI2 patch
On Sat, 2025-06-21 at 21:33 +0200, chia-yu.chang@...ia-bell-labs.com wrote:
> From: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
>
> Hello,
>
> Please find the DualPI2 patch v20.
>
> This patch serise adds DualPI Improved with a Square (DualPI2) with
> following features:
> * Supports congestion controls that comply with the Prague requirements in
> RFC9331 (e.g. TCP-Prague)
> * Coupled dual-queue that separates the L4S traffic in a low latency queue (L-
> queue), without harming remaining traffic that is scheduled in classic queue
> (C-queue) due to congestion-coupling using PI2 as defined in RFC9332
> * Configurable overload strategies
> * Use of sojourn time to reliably estimate queue delay
> * Supports ECN L4S-identifier (IP.ECN==0b*1) to classify traffic into
> respective queues
>
Looking at this, I wonder if DualPI2 would be implemented in BPF.
For example, you could have two FIFOs with a BPF Qdisc, such as:
struct bpf_list_head l_queue __contains(skb_node, node);
struct bpf_list_head c_queue __contains(skb_node, node);
The bpf_list_push_back and bpf_list_pop_front functions are also available for
handling these.
There are also spinlock helpers, and the pi2_timer can be replaced with updates
based on the struct bpf_timer. Of course, there are tricks to consider regarding
GSO, which might require additional BPF helpers. However, looking through the
code, I see a chance to implement this as a pure BPF qdisc. What do you think?
Having this as a regular qdisc with the iproute2 tc interface is great,
considering the effort already spent on it. However, since all the operational
bits are already sorted out, it might be worth looking into the feasibility of a
BPF version.
Best,
Ferenc
Powered by blists - more mailing lists