[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240530091330.13a20fdc@kernel.org>
Date: Thu, 30 May 2024 09:13:30 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Vladimir Oltean <olteanv@...il.com>, Xiaolei Wang
<xiaolei.wang@...driver.com>, Andrew Lunn <andrew@...n.ch>,
alexandre.torgue@...s.st.com, joabreu@...opsys.com, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, mcoquelin.stm32@...il.com,
netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [net v2 PATCH] net: stmmac: Update CBS parameters when speed
changes after linking up
On Thu, 30 May 2024 14:40:30 +0100 Russell King (Oracle) wrote:
> I think what you're proposing leads to the hardware being effectively
> "de-programmed" for CBS while "tc qdisc show" will probably report
> that CBS is active on the interface - which clearly would be absurd.
FWIW the "switch-offloaded" qdiscs do support reporting that they got
"de-programmed" given that more complex hierarchies can easily go out
of what HW is capable of.
They call the driver from the .dump callback, nominally to get
stats (e.g. red_dump() -> red_dump_offload_stats()) but it also
refreshes the offloaded state (see qdisc_offload_dump_helper()).
For "NIC-offloaded" qdiscs (i.e. all traffic passes thru the host,
rather than being forwarded) the stats callback makes less sense.
But all this is to say that there _is_ precedent for clearing
qdisc "offloaded" bits.
Powered by blists - more mailing lists