[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240816114817.gp7m6k2rlz7s4e5a@skbuf>
Date: Fri, 16 Aug 2024 14:48:17 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Furong Xu <0x1207@...il.com>
Cc: Serge Semin <fancer.lancer@...il.com>, Andrew Lunn <andrew@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Joao Pinto <jpinto@...opsys.com>, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
xfr@...look.com, rock.xu@....com
Subject: Re: [PATCH net-next v2 0/7] net: stmmac: FPE via ethtool + tc
On Tue, Aug 13, 2024 at 07:47:26PM +0800, Furong Xu wrote:
> Move the Frame Preemption(FPE) over to the new standard API which uses
> ethtool-mm/tc-mqprio/tc-taprio.
>
> Changes in v2:
> 1. refactor FPE verification processe
> 2. suspend/resume and kselftest-ethtool_mm, all test cases passed
> 3. handle TC:TXQ remapping for DWMAC CORE4+
This is starting to look better and better. I wouldn't be sad if it was
merged like this, but the locking still looks a little bit wacky to me,
and it's not 100% clear what priv->mm_lock protects and what it doesn't.
I can make a breakdown of how each member of fpe_cfg is used, and thus
understand exactly what are the locking needs and how they are addressed
in this version, but most likely not today.
Powered by blists - more mailing lists