From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Furong Xu <0x1207@gmail.com>
Cc: Serge Semin <fancer.lancer@gmail.com>,
Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Joao Pinto <jpinto@synopsys.com>, <netdev@vger.kernel.org>,
<linux-stm32@st-md-mailman.stormreply.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <xfr@outlook.com>
Subject: Re: [PATCH net-next v4 5/7] net: stmmac: support fp parameter of tc-mqprio
Date: Tue, 20 Aug 2024 17:00:18 +0200 [thread overview]
Message-ID: <821f0baf-8e40-4623-b342-1028c92e5519@intel.com> (raw)
In-Reply-To: <413a36781a9b215c857bd8ec3c9ee03462e861d7.1724145786.git.0x1207@gmail.com>
From: Furong Xu <0x1207@gmail.com>
Date: Tue, 20 Aug 2024 17:38:33 +0800
> tc-mqprio can select whether traffic classes are express or preemptible.
>
> After some traffic tests, MAC merge layer statistics are all good.
[...]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> index 4c91fa766b13..1e87dbc9a406 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> @@ -670,3 +670,55 @@ void dwmac5_fpe_set_add_frag_size(void __iomem *ioaddr, u32 add_frag_size)
>
> writel(value, ioaddr + MTL_FPE_CTRL_STS);
> }
> +
> +int dwmac5_fpe_set_preemptible_tcs(struct net_device *ndev,
> + struct netlink_ext_ack *extack,
> + unsigned long tcs)
> +{
> + struct stmmac_priv *priv = netdev_priv(ndev);
Can't it be const?
> + void __iomem *ioaddr = priv->ioaddr;
> + unsigned long queue_tcs = 0;
Why is @tcs and @queue_tcs unsigned long? You write @queue_tcs via
writel(), IOW it can't go past %U32_MAX.
> + int num_tc = ndev->num_tc;
> + u32 value, queue_weight;
> + u16 offset, count;
Just use u32 here for all three.
> + int tc, i;
> +
> + if (!tcs)
> + goto __update_queue_tcs;
> +
> + for (tc = 0; tc < num_tc; tc++) {
@tc can be declared right here in the loop declaration.
Also it's u32 as it can't be negative.
> + count = ndev->tc_to_txq[tc].count;
> + offset = ndev->tc_to_txq[tc].offset;
> +
> + if (tcs & BIT(tc))
> + queue_tcs |= GENMASK(offset + count - 1, offset);
> +
> + /* This is 1:1 mapping, go to next TC */
> + if (count == 1)
> + continue;
> +
> + if (priv->plat->tx_sched_algorithm == MTL_TX_ALGORITHM_SP) {
> + NL_SET_ERR_MSG_MOD(extack, "TX algorithm SP is not suitable for one TC to multiple TXQs mapping");
> + return -EINVAL;
> + }
> +
> + queue_weight = priv->plat->tx_queues_cfg[offset].weight;
> + for (i = 1; i < count; i++) {
Same as with @tc for everything.
> + if (queue_weight != priv->plat->tx_queues_cfg[offset + i].weight) {
> + NL_SET_ERR_MSG_FMT_MOD(extack, "TXQ weight [%u] differs across other TXQs in TC: [%u]",
> + queue_weight, tc);
> + return -EINVAL;
> + }
> + }
> + }
> +
> +__update_queue_tcs:
Again underscores.
> + value = readl(ioaddr + MTL_FPE_CTRL_STS);
> +
> + value &= ~PEC;
> + value |= FIELD_PREP(PEC, queue_tcs);
> +
> + writel(value, ioaddr + MTL_FPE_CTRL_STS);
These are also u32_replace_bits() as in the previous patch.
> +
> + return 0;
> +}
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.h b/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
> index e369e65920fc..d3191c48354d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.h
> @@ -40,6 +40,7 @@
> #define MAC_PPSx_WIDTH(x) (0x00000b8c + ((x) * 0x10))
>
> #define MTL_FPE_CTRL_STS 0x00000c90
> +#define PEC GENMASK(15, 8)
Again some driver prefix would be nice to see.
> #define AFSZ GENMASK(1, 0)
>
> #define MTL_RXP_CONTROL_STATUS 0x00000ca0
[...]
> @@ -1174,6 +1175,13 @@ static int tc_query_caps(struct stmmac_priv *priv,
> struct tc_query_caps_base *base)
> {
> switch (base->type) {
> + case TC_SETUP_QDISC_MQPRIO: {
> + struct tc_mqprio_caps *caps = base->caps;
> +
> + caps->validate_queue_counts = true;
Why not base->caps->blah directly? I think it would fit 80 cols?
> +
> + return 0;
> + }
> case TC_SETUP_QDISC_TAPRIO: {
> struct tc_taprio_caps *caps = base->caps;
>
> @@ -1190,6 +1198,78 @@ static int tc_query_caps(struct stmmac_priv *priv,
> }
> }
>
> +static void stmmac_reset_tc_mqprio(struct net_device *ndev,
> + struct netlink_ext_ack *extack)
> +{
> + struct stmmac_priv *priv = netdev_priv(ndev);
> +
> + netdev_reset_tc(ndev);
> + netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
> +
> + stmmac_fpe_set_preemptible_tcs(priv, ndev, extack, 0);
> +}
> +
> +static int tc_setup_mqprio(struct stmmac_priv *priv,
> + struct tc_mqprio_qopt_offload *mqprio)
> +{
> + struct netlink_ext_ack *extack = mqprio->extack;
> + struct tc_mqprio_qopt *qopt = &mqprio->qopt;
> + struct net_device *ndev = priv->dev;
> + int num_stack_tx_queues = 0;
> + int num_tc = qopt->num_tc;
> + u16 offset, count;
Also u32 for most of these.
> + int tc, err;
> +
> + if (!num_tc) {
> + stmmac_reset_tc_mqprio(ndev, extack);
> + return 0;
> + }
> +
> + if (mqprio->preemptible_tcs && !ethtool_dev_mm_supported(ndev)) {
> + NL_SET_ERR_MSG_MOD(extack, "Device does not support preemption");
> + return -EOPNOTSUPP;
> + }
> +
> + err = netdev_set_num_tc(ndev, num_tc);
> + if (err)
> + return err;
> +
> + /* DWMAC CORE4+ can not programming TC:TXQ mapping to hardware.
"can't program" or "can't do programming" or "doesn't support programming".
> + * Synopsys Databook:
> + * "The number of Tx DMA channels is equal to the number of Tx queues,
> + * and is direct one-to-one mapping."
> + *
> + * Luckily, DWXGMAC CORE can.
> + *
> + * Thus preemptible_tcs should be handled in a per core manner.
> + */
[...]
Thanks,
Olek
next prev parent reply other threads:[~2024-08-20 15:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-20 9:38 [PATCH net-next v4 0/7] net: stmmac: FPE via ethtool + tc Furong Xu
2024-08-20 9:38 ` [PATCH net-next v4 1/7] net: stmmac: move stmmac_fpe_cfg to stmmac_priv data Furong Xu
2024-08-20 9:55 ` Vladimir Oltean
2024-08-20 9:38 ` [PATCH net-next v4 2/7] net: stmmac: drop stmmac_fpe_handshake Furong Xu
2024-08-20 9:56 ` Vladimir Oltean
2024-08-20 9:38 ` [PATCH net-next v4 3/7] net: stmmac: refactor FPE verification process Furong Xu
2024-08-20 12:34 ` Vladimir Oltean
2024-08-20 12:52 ` Vladimir Oltean
2024-08-21 4:58 ` Furong Xu
2024-08-21 10:27 ` Vladimir Oltean
2024-08-20 14:36 ` Alexander Lobakin
2024-08-20 9:38 ` [PATCH net-next v4 4/7] net: stmmac: configure FPE via ethtool-mm Furong Xu
2024-08-20 14:48 ` Alexander Lobakin
2024-08-20 9:38 ` [PATCH net-next v4 5/7] net: stmmac: support fp parameter of tc-mqprio Furong Xu
2024-08-20 9:51 ` Vladimir Oltean
2024-08-20 15:00 ` Alexander Lobakin [this message]
2024-08-20 9:38 ` [PATCH net-next v4 6/7] net: stmmac: support fp parameter of tc-taprio Furong Xu
2024-08-20 9:38 ` [PATCH net-next v4 7/7] net: stmmac: silence FPE kernel logs Furong Xu
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=821f0baf-8e40-4623-b342-1028c92e5519@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=0x1207@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fancer.lancer@gmail.com \
--cc=joabreu@synopsys.com \
--cc=jpinto@synopsys.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=xfr@outlook.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
all inboxes | Powered by JetHome®