[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PAXPR07MB7984F85A786D9B35898ECEBDA346A@PAXPR07MB7984.eurprd07.prod.outlook.com>
Date: Mon, 30 Jun 2025 15:51:11 +0000
From: "Chia-Yu Chang (Nokia)" <chia-yu.chang@...ia-bell-labs.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "alok.a.tiwari@...cle.com" <alok.a.tiwari@...cle.com>,
"pctammela@...atatu.com" <pctammela@...atatu.com>, "horms@...nel.org"
<horms@...nel.org>, "donald.hunter@...il.com" <donald.hunter@...il.com>,
"xandfury@...il.com" <xandfury@...il.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "dave.taht@...il.com" <dave.taht@...il.com>,
"pabeni@...hat.com" <pabeni@...hat.com>, "jhs@...atatu.com"
<jhs@...atatu.com>, "stephen@...workplumber.org"
<stephen@...workplumber.org>, "xiyou.wangcong@...il.com"
<xiyou.wangcong@...il.com>, "jiri@...nulli.us" <jiri@...nulli.us>,
"davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
<edumazet@...gle.com>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
"ast@...erby.net" <ast@...erby.net>, "liuhangbin@...il.com"
<liuhangbin@...il.com>, "shuah@...nel.org" <shuah@...nel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"ij@...nel.org" <ij@...nel.org>, "ncardwell@...gle.com"
<ncardwell@...gle.com>, "Koen De Schepper (Nokia)"
<koen.de_schepper@...ia-bell-labs.com>, "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>
Subject: RE: [PATCH v20 net-next 1/6] sched: Struct definition and parsing of
dualpi2 qdisc
> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Monday, June 30, 2025 5:14 PM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@...ia-bell-labs.com>
> Cc: 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; 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 (Nokia) <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 1/6] sched: Struct definition and parsing of dualpi2 qdisc
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On Sun, 29 Jun 2025 22:49:24 +0000 Chia-Yu Chang (Nokia) wrote:
> > > I don't get the reason for all these WRITE_ONCE()s.
> > > You lock the qdisc to make modifications, right?
> > > And the block under which I'm responding is performing two dependent writes, one to ->step_in_packets and the other to ->step_thresh a change which is definitely not atomic..
> >
> > Thanks again for other comments again, and I will take actions in the next version.
> >
> > As there is only one step marking in L-queue, so we still need two
> > WRITE_ONCE even two attributes (one for threshold in packets and one
> > in time) are used.
> >
> > When applying the step marking, we need to know either the computation
> > is based on the sojourn time or queue length.
>
> Let me ask again - why do you use WRITE_ONCE() at all if the modification takes the qdisc lock? Which reader are you afraid of racing with?
This still needs 2 WRITE_ONCE even "step_thresh" (NLA_U32) and "step_in_packtes" (NLA_FLAG) are replaced with "step_pkt_thresh" (NLA_U32) and "step_time_thresh" (NLA_U32) - which was proposed in my another email.
Because we need to know which kind of AQM is applied, either based on # of packets or sojourn time in the L-queue.
And the corresponding reader will be at the dualpi2_dump.
Powered by blists - more mailing lists