All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Xiaolei Wang <xiaolei.wang@windriver.com>,
	Andrew Lunn <andrew@lunn.ch>,
	alexandre.torgue@foss.st.com, joabreu@synopsys.com,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [net v2 PATCH] net: stmmac: Update CBS parameters when speed changes after linking up
Date: Thu, 30 May 2024 09:13:30 -0700	[thread overview]
Message-ID: <20240530091330.13a20fdc@kernel.org> (raw)
In-Reply-To: <ZliBzo7eETml/+bl@shell.armlinux.org.uk>

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Vladimir Oltean <olteanv@gmail.com>,
	Xiaolei Wang <xiaolei.wang@windriver.com>,
	Andrew Lunn <andrew@lunn.ch>,
	alexandre.torgue@foss.st.com, joabreu@synopsys.com,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [net v2 PATCH] net: stmmac: Update CBS parameters when speed changes after linking up
Date: Thu, 30 May 2024 09:13:30 -0700	[thread overview]
Message-ID: <20240530091330.13a20fdc@kernel.org> (raw)
In-Reply-To: <ZliBzo7eETml/+bl@shell.armlinux.org.uk>

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.

  parent reply	other threads:[~2024-05-30 16:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-30  6:14 [net v2 PATCH] net: stmmac: Update CBS parameters when speed changes after linking up Xiaolei Wang
2024-05-30  6:14 ` Xiaolei Wang
2024-05-30 12:50 ` Andrew Lunn
2024-05-30 12:50   ` Andrew Lunn
2024-05-30 13:28   ` Vladimir Oltean
2024-05-30 13:28     ` Vladimir Oltean
2024-05-30 13:40     ` Russell King (Oracle)
2024-05-30 13:40       ` Russell King (Oracle)
2024-05-30 13:53       ` Vladimir Oltean
2024-05-30 13:53         ` Vladimir Oltean
2024-05-30 14:14         ` Russell King (Oracle)
2024-05-30 14:14           ` Russell King (Oracle)
2024-05-30 14:35           ` Vladimir Oltean
2024-05-30 14:35             ` Vladimir Oltean
2024-05-31  8:23             ` xiaolei wang
2024-05-31  8:23               ` xiaolei wang
2024-05-30 16:13       ` Jakub Kicinski [this message]
2024-05-30 16:13         ` Jakub Kicinski
2024-06-05  5:26 ` Dan Carpenter
2024-06-05  5:26   ` Dan Carpenter
2024-06-05  5:30   ` xiaolei wang
2024-06-05  5:30     ` xiaolei wang
  -- strict thread matches above, loose matches on Subject: below --
2024-06-04 20:04 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240530091330.13a20fdc@kernel.org \
    --to=kuba@kernel.org \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=joabreu@synopsys.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=xiaolei.wang@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.