netdev - Re: [PATCH v2 net-next 15/15] net/sched: taprio: only calculate gate mask per TXQ for igc, stmmac and tsnep

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 26 Jan 2023 20:21:15 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     "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>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Siddharth Vadapalli <s-vadapalli@...com>,
        Roger Quadros <rogerq@...nel.org>
Subject: Re: [PATCH v2 net-next 15/15] net/sched: taprio: only calculate gate
 mask per TXQ for igc, stmmac and tsnep

On 26.01.23 13:53, Vladimir Oltean wrote:
> There are 2 classes of in-tree drivers currently:
> 
> - those who act upon struct tc_taprio_sched_entry :: gate_mask as if it
>    holds a bit mask of TXQs
> 
> - those who act upon the gate_mask as if it holds a bit mask of TCs
> 
> When it comes to the standard, IEEE 802.1Q-2018 does say this in the
> second paragraph of section 8.6.8.4 Enhancements for scheduled traffic:
> 
> | A gate control list associated with each Port contains an ordered list
> | of gate operations. Each gate operation changes the transmission gate
> | state for the gate associated with each of the Port's traffic class
> | queues and allows associated control operations to be scheduled.
> 
> In typically obtuse language, it refers to a "traffic class queue"
> rather than a "traffic class" or a "queue". But careful reading of
> 802.1Q clarifies that "traffic class" and "queue" are in fact
> synonymous (see 8.6.6 Queuing frames):
> 
> | A queue in this context is not necessarily a single FIFO data structure.
> | A queue is a record of all frames of a given traffic class awaiting
> | transmission on a given Bridge Port. The structure of this record is not
> | specified.
> 
> i.o.w. their definition of "queue" isn't the Linux TX queue.
> 
> The gate_mask really is input into taprio via its UAPI as a mask of
> traffic classes, but taprio_sched_to_offload() converts it into a TXQ
> mask.
> 
> The breakdown of drivers which handle TC_SETUP_QDISC_TAPRIO is:
> 
> - hellcreek, felix, sja1105: these are DSA switches, it's not even very
>    clear what TXQs correspond to, other than purely software constructs.
>    For felix and sja1105, I can confirm that only the mqprio
>    configuration with 8 TCs and 1 TXQ per TC makes sense. So it's fine to
>    convert these to a gate mask per TC.
> 
> - enetc: I have the hardware and can confirm that the gate mask is per
>    TC, and affects all TXQs (BD rings) configured for that priority.
> 
> - igc: in igc_save_qbv_schedule(), the gate_mask is clearly interpreted
>    to be per-TXQ.
> 
> - tsnep: Gerhard Engleder clarifies that even though this hardware
>    supports at most 1 TXQ per TC, the TXQ indices may be different from
>    the TC values themselves, and it is the TXQ indices that matter to
>    this hardware. So keep it per-TXQ as well.
> 
> - stmmac: I have a GMAC datasheet, and in the EST section it does
>    specify that the gate events are per TXQ rather than per TC.
> 
> - lan966x: again, this is a switch, and while not a DSA one, the way in
>    which it implements lan966x_mqprio_add() - by only allowing num_tc ==
>    NUM_PRIO_QUEUES (8) - makes it clear to me that TXQs are a purely
>    software construct here as well. They seem to map 1:1 with TCs.
> 
> - am65_cpsw: from looking at am65_cpsw_est_set_sched_cmds(), I get the
>    impression that the fetch_allow variable is treated like a prio_mask.
>    I haven't studied this driver's interpretation of the prio_tc_map, but
>    that definitely sounds closer to a per-TC gate mask rather than a
>    per-TXQ one.
> 
> Based on this breakdown, we have 6 drivers with a gate mask per TC and
> 3 with a gate mask per TXQ. So let's make the gate mask per TXQ the
> opt-in and the gate mask per TC the default.
> 
> Benefit from the TC_QUERY_CAPS feature that Jakub suggested we add, and
> query the device driver before calling the proper ndo_setup_tc(), and
> figure out if it expects one or the other format.
> 
> Cc: Gerhard Engleder <gerhard@...leder-embedded.com>
> Cc: Horatiu Vultur <horatiu.vultur@...rochip.com>
> Cc: Siddharth Vadapalli <s-vadapalli@...com>
> Cc: Roger Quadros <rogerq@...nel.org>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> ---
> v1->v2:
> - rewrite commit message
> - also opt in stmmac and tsnep
> 
>   drivers/net/ethernet/engleder/tsnep_tc.c      | 21 +++++++++++++++++
>   drivers/net/ethernet/intel/igc/igc_main.c     | 23 +++++++++++++++++++
>   drivers/net/ethernet/stmicro/stmmac/hwif.h    |  5 ++++
>   .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 ++
>   .../net/ethernet/stmicro/stmmac/stmmac_tc.c   | 20 ++++++++++++++++
>   include/net/pkt_sched.h                       |  1 +
>   net/sched/sch_taprio.c                        | 11 ++++++---
>   7 files changed, 80 insertions(+), 3 deletions(-)

Reviewed-by: Gerhard Engleder <gerhard@...leder-embedded.com>