netdev - Re: [PATCH v4 net-next 11/15] net: enetc: act upon the requested mqprio queue configuration

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y9qCFtb6RBUZ4+Wj@corigine.com>
Date:   Wed, 1 Feb 2023 16:15:34 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH v4 net-next 11/15] net: enetc: act upon the requested
 mqprio queue configuration

On Mon, Jan 30, 2023 at 07:31:41PM +0200, Vladimir Oltean wrote:
> Regardless of the requested queue count per traffic class, the enetc
> driver allocates a number of TX rings equal to the number of TCs, and
> hardcodes a queue configuration of "1@0 1@1 ... 1@...-tc". Other
> configurations are silently ignored and treated the same.
> 
> Improve that by allowing what the user requests to be actually
> fulfilled. This allows more than one TX ring per traffic class.
> For example:
> 
> $ tc qdisc add dev eno0 root handle 1: mqprio num_tc 4 \
> 	map 0 0 1 1 2 2 3 3 queues 2@0 2@2 2@4 2@6
> [  146.267648] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0
> [  146.273451] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 0
> [  146.283280] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 1
> [  146.293987] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 1
> [  146.300467] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 2
> [  146.306866] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 2
> [  146.313261] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 3
> [  146.319622] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 3
> $ tc qdisc del dev eno0 root
> [  178.238418] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0
> [  178.244369] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 0
> [  178.251486] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 0
> [  178.258006] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 0
> [  178.265038] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 0
> [  178.271557] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 0
> [  178.277910] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 0
> [  178.284281] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 0
> $ tc qdisc add dev eno0 root handle 1: mqprio num_tc 8 \
> 	map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 1
> [  186.113162] fsl_enetc 0000:00:00.0 eno0: TX ring 0 prio 0
> [  186.118764] fsl_enetc 0000:00:00.0 eno0: TX ring 1 prio 1
> [  186.124374] fsl_enetc 0000:00:00.0 eno0: TX ring 2 prio 2
> [  186.130765] fsl_enetc 0000:00:00.0 eno0: TX ring 3 prio 3
> [  186.136404] fsl_enetc 0000:00:00.0 eno0: TX ring 4 prio 4
> [  186.142049] fsl_enetc 0000:00:00.0 eno0: TX ring 5 prio 5
> [  186.147674] fsl_enetc 0000:00:00.0 eno0: TX ring 6 prio 6
> [  186.153305] fsl_enetc 0000:00:00.0 eno0: TX ring 7 prio 7
> 
> The driver used to set TC_MQPRIO_HW_OFFLOAD_TCS, near which there is
> this comment in the UAPI header:
> 
>         TC_MQPRIO_HW_OFFLOAD_TCS,       /* offload TCs, no queue counts */
> 
> but I'm not sure who even looks at this field. Anyway, since this is
> basically what enetc was doing up until now (and no longer is; we
> offload queue counts too), remove that assignment.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Simon Horman <simon.horman@...igine.com>