From: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
To: Daniel Machon <daniel.machon@microchip.com>
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Davide Caratti <dcaratti@redhat.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Daniel Thompson <daniel@riscstar.com>
Subject: Re: [PATCH net-next] net: stmmac: fix mqprio and cbs combination
Date: Tue, 13 Oct 2026 14:24:45 +0200 [thread overview]
Message-ID: <as4jDfpsvIfsZp_M@lore-desk> (raw)
In-Reply-To: <20261013104325.j526p5yurc5zmzhn@DEN-DL-M70577.microsemi.net>
[-- Attachment #1: Type: text/plain, Size: 5970 bytes --]
> > On Oct 13, Daniel Machon wrote:
> > > Hi Lorenzo,
> > >
> > > Just a question:
> > >
> > > > The channel-mode mqprio offload and the CBS offload can currently not be
> > > > enabled at the same time. tc_mqprio_validate_chan_mode() refuses the
> > > > mqprio offload as soon as any TX queue is configured in AVB mode, and
> > > > tc_setup_cbs() refuses to enable CBS while the strict-priority scheduler
> > > > is active. As a result the combination is rejected whichever order the
> > > > two are configured in.
> > > >
> > > > The strict-priority scheduler selected by the channel-mode mqprio
> > > > offload and the per-queue CBS shaper are independent MTL settings and do
> > > > not conflict, so drop the checks and let the combination be offloaded.
> > > > The following configuration, which was previously refused, now works:
> > >
> > > Looks to me like these checks are shared by multiple cores. Are the MTL settings
> > > independent on all of them?
> >
> > Can you please explain what you mean?
> > What I mean with this patch is we can have a given queue (e.g. queue X)
> > configured in MTL_QUEUE_AVB mode and another one (e.g. queue Y) configured
> > in MTL_QUEUE_DCB mode.
>
> Sorry for being vague. I meant the MAC cores. So, dwmac510_tc_ops is being used
> by GMAC, XGMAC, XLGMAC. My question was whether the claim that the commit
> description gives (per-queue CBS shaper are independent MTL settings) apply to
> all of these 3?
Yes, according to my understanding. MTL_QUEUE_AVB and MTL_QUEUE_DCB are
mutually exclusive for a specific queue, but there is no restriction on two
different hw queues (MTL_QUEUE_AVB and MTL_QUEUE_DCB can be mixed).
Regards,
Lorenzo
>
> >
> > Regards,
> > Lorenzo
> >
> > >
> > > >
> > > > $ tc qdisc replace dev eth0 handle 100 parent root mqprio num_tc 4 \
> > > > map 0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0 \
> > > > queues 1@0 1@1 1@2 1@3 mode channel hw 1
> > > > $ tc qdisc replace dev eth0 parent 100:2 handle 102: cbs \
> > > > idleslope 800000 sendslope -1700000 hicredit 494 locredit -1049 offload 0
> > > > $ tc qdisc replace dev eth0 parent 100:3 handle 103: cbs \
> > > > idleslope 400000 sendslope -2100000 hicredit 247 locredit -1296 offload 1
> > > > $ tc qdisc replace dev eth0 parent 100:4 handle 104: cbs \
> > > > idleslope 200000 sendslope -2300000 hicredit 124 locredit -1419 offload 1
> > > >
> > > > Fixes: 47891d501e34 ("net: stmmac: add tc mqprio hw queue priority offload")
> > > > Tested-by: Daniel Thompson <daniel@riscstar.com>
> > > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > > ---
> > > > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 --------
> > > > drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 16 ----------------
> > > > 2 files changed, 24 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > index 56d89a696272..51d502930219 100644
> > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > @@ -7740,14 +7740,6 @@ int stmmac_reinit_queues(struct net_device *dev, u8 rx_cnt, u8 tx_cnt)
> > > > tx_cnt < priv->xmit_qdisc.num_tx_queues)
> > > > return -EINVAL;
> > > >
> > > > - if (priv->xmit_qdisc.prio_offload) {
> > > > - for (i = priv->plat->tx_queues_to_use; i < tx_cnt; i++) {
> > > > - if (priv->plat->tx_queues_cfg[i].mode_to_use ==
> > > > - MTL_QUEUE_AVB)
> > > > - return -EINVAL;
> > > > - }
> > > > - }
> > > > -
> > > > if (netif_running(dev))
> > > > stmmac_release(dev);
> > > >
> > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> > > > index ea1f97d6f0bd..175236ba379d 100644
> > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> > > > @@ -346,9 +346,6 @@ static int tc_setup_cbs(struct stmmac_priv *priv,
> > > > if (!priv->dma_cap.av)
> > > > return -EOPNOTSUPP;
> > > >
> > > > - if (qopt->enable && priv->xmit_qdisc.prio_offload)
> > > > - return -EOPNOTSUPP;
> > > > -
> > > > port_transmit_rate_kbps = qopt->idleslope - qopt->sendslope;
> > > >
> > > > if (qopt->enable) {
> > > > @@ -1340,7 +1337,6 @@ static void tc_mqprio_config_queue_prio(struct stmmac_priv *priv,
> > > > static int tc_mqprio_validate_chan_mode(struct stmmac_priv *priv,
> > > > struct tc_mqprio_qopt_offload *mqprio)
> > > > {
> > > > - struct plat_stmmacenet_data *pdata = priv->plat;
> > > > struct tc_mqprio_qopt *qopt = &mqprio->qopt;
> > > > int i;
> > > >
> > > > @@ -1350,18 +1346,6 @@ static int tc_mqprio_validate_chan_mode(struct stmmac_priv *priv,
> > > > return -EOPNOTSUPP;
> > > > }
> > > >
> > > > - /* Forcing strict priority conflicts with the CBS algorithm
> > > > - * of AVB queues, so reject the offload when any queue is
> > > > - * configured as AVB.
> > > > - */
> > > > - for (i = 0; i < pdata->tx_queues_to_use; i++) {
> > > > - if (pdata->tx_queues_cfg[i].mode_to_use == MTL_QUEUE_AVB) {
> > > > - NL_SET_ERR_MSG_MOD(mqprio->extack,
> > > > - "SP conflicts with AVB queues");
> > > > - return -EOPNOTSUPP;
> > > > - }
> > > > - }
> > > > -
> > > > for (i = 0; i < qopt->num_tc; i++) {
> > > > /* The offload switches the MTL scheduler to strict
> > > > * priority, which only supports a 1:1 TC to TX queue
> > > >
> > > > ---
> > > > base-commit: d0bd617658ddfa5a115e64d1ab687bf155f6331f
> > > > change-id: 20261012-stmmac-mqprio-cbs-combo-341f12749ce2
> > > >
> > > > Best regards,
> > > > --
> > > > Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
> > > >
> > >
> > > /Daniel
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-10-13 12:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 21:14 [PATCH net-next] net: stmmac: fix mqprio and cbs combination Lorenzo Bianconi
2026-10-13 9:51 ` Daniel Thompson
2026-10-13 9:58 ` Maxime Chevallier
2026-10-13 10:10 ` Daniel Machon
2026-10-13 10:21 ` Lorenzo Bianconi
2026-10-13 10:43 ` Daniel Machon
2026-10-13 12:24 ` Lorenzo Bianconi [this message]
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=as4jDfpsvIfsZp_M@lore-desk \
--to=lorenzo.bianconi@oss.qualcomm.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=daniel.machon@microchip.com \
--cc=daniel@riscstar.com \
--cc=davem@davemloft.net \
--cc=dcaratti@redhat.com \
--cc=edumazet@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox