| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20240801230725.nllk7n3veqwplfpo@skbuf>
Date: Fri, 2 Aug 2024 02:07:25 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Furong Xu <0x1207@...il.com>
Cc: 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 v1 2/5] net: stmmac: support fp parameter of
tc-mqprio
On Wed, Jul 31, 2024 at 06:43:13PM +0800, Furong Xu wrote:
> tc-mqprio can select whether traffic classes are express or preemptible.
>
> Tested on DWMAC CORE 5.10a
>
> Signed-off-by: Furong Xu <0x1207@...il.com>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +
> drivers/net/ethernet/stmicro/stmmac/dwmac5.c | 12 ++++
> drivers/net/ethernet/stmicro/stmmac/dwmac5.h | 2 +
> drivers/net/ethernet/stmicro/stmmac/hwif.h | 8 +++
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +
> .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 61 +++++++++++++++++++
> 6 files changed, 87 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> index 5d132bada3fe..068859284691 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
> @@ -655,3 +655,15 @@ void dwmac5_fpe_set_add_frag_size(void __iomem *ioaddr, u32 add_frag_size)
>
> writel(value, ioaddr + MTL_FPE_CTRL_STS);
> }
> +
> +void dwmac5_fpe_set_preemptible_tcs(void __iomem *ioaddr, unsigned long tcs)
> +{
> + u32 value;
> +
> + value = readl(ioaddr + MTL_FPE_CTRL_STS);
> +
> + value &= ~PEC;
> + value |= FIELD_PREP(PEC, tcs);
> +
> + writel(value, ioaddr + MTL_FPE_CTRL_STS);
> +}
Watch out here. I think the MTL_FPE_CTRL_STS[PEC] field is per TXQ, but
input from user space is per TC. There's a difference between the 2, that I'll
try to clarify below. But even ignoring the case of multiple TXQs per TC,
there's also the case of reverse TC:TXQ mappings: "num_tc 4 map 0 1 2 3
queues 1@3 1@2 1@1 1@0". When the user then says he wants TC 0 to be
preemptible, he really means TXQ 3. That's how this should be treated.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 9b1cf81c50ea..a5e3316bc410 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6256,6 +6256,8 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
> switch (type) {
> case TC_QUERY_CAPS:
> return stmmac_tc_query_caps(priv, priv, type_data);
> + case TC_SETUP_QDISC_MQPRIO:
> + return stmmac_tc_setup_mqprio(priv, priv, type_data);
> case TC_SETUP_BLOCK:
> return flow_block_cb_setup_simple(type_data,
> &stmmac_block_cb_list,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> index 996f2bcd07a2..494fe2f68300 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
> @@ -1198,6 +1198,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;
> +
> + return 0;
> + }
> case TC_SETUP_QDISC_TAPRIO: {
> struct tc_taprio_caps *caps = base->caps;
>
> @@ -1214,6 +1221,59 @@ static int tc_query_caps(struct stmmac_priv *priv,
> }
> }
>
> +static void stmmac_reset_tc_mqprio(struct net_device *ndev)
> +{
> + 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, priv->ioaddr, 0);
> +}
> +
> +static int tc_setup_mqprio(struct stmmac_priv *priv,
> + struct tc_mqprio_qopt_offload *mqprio)
> +{
> + 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;
> + int offset, count;
> + int tc, err;
> +
> + if (!num_tc) {
> + stmmac_reset_tc_mqprio(ndev);
> + return 0;
> + }
> +
> + err = netdev_set_num_tc(ndev, num_tc);
> + if (err)
> + return err;
> +
> + for (tc = 0; tc < num_tc; tc++) {
> + offset = qopt->offset[tc];
> + count = qopt->count[tc];
> + num_stack_tx_queues += count;
> +
> + err = netdev_set_tc_queue(ndev, tc, count, offset);
> + if (err)
> + goto err_reset_tc;
> + }
We might have a problem here, and I don't know if I'm well enough
equipped with DWMAC knowledge to help you solve it.
The way I understand mqprio is that it groups TX queues into traffic
classes. All traffic classes are in strict priority relative to each
other (TC 0 having the smallest priority). If multiple TX queues go to
the same traffic class, it is expected that the NIC performs round robin
dequeuing out of them. Then there's a prio_tc_map[], which maps
skb->priority values to traffic classes. On xmit, netdev_pick_tx()
chooses a random TX queue out of those assigned to the computed traffic
class for the packet. This skb_tx_hash() is the software enqueue
counterpart to what the NIC is expected to do in terms of scheduling.
Much of this is said in newer versions of "man tc-mqprio".
https://man7.org/linux/man-pages/man8/tc-mqprio.8.html
Where I was trying to get is that you aren't programming the TC to TXQ
mapping to hardware in any way, and you are accepting any mapping that
the user requests. This isn't okay.
I believe that the DWMAC TX scheduling algorithm is strict priority by
default, with plat->tx_sched_algorithm being configurable through device
tree properties to other values. Then, individual TX queues have the
"snps,priority" device tree property for configuring their scheduling
priority. All of that can go out of sync with what the user thinks he
configures through tc-mqprio, and badly.
Consider "num_tc 2 queues 3@0 2@3". The stack will think that TXQs 0, 1, 2
have one priority, and TXQs 3 and 4 another. But in reality, each TXQ
(say by default) has a priority equal to its index. netdev_pick_tx()
will think it's okay, for a packet belonging to TC0, to select a TXQ
based on hashing between indices 0, 1, 2. But in hardware, the packets
will get sent through TXQs with different priorities, based on nothing
more than pure chance. That is a disaster, and especially noticeable
when the mqprio mapping is applied through taprio, and there is a Qbv
schedule on the port. Some packets will be scheduled on the right time
slots, and some won't.
So the idea here is that you'll either have to experiment with
reprogramming the scheduling algorithm and TXQ priorities on mqprio
offload, or refuse offloading anything that doesn't match what the
hardware was pre-programmed with (through device tree, likely).
> +
> + err = netif_set_real_num_tx_queues(ndev, num_stack_tx_queues);
> + if (err)
> + goto err_reset_tc;
> +
> + stmmac_fpe_set_preemptible_tcs(priv, priv->ioaddr, mqprio->preemptible_tcs);
> +
> + return 0;
> +
> +err_reset_tc:
> + stmmac_reset_tc_mqprio(ndev);
> +
> + return err;
> +}
Powered by blists - more mailing lists