[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v8ktza94.fsf@kurt>
Date: Thu, 26 Jan 2023 14:38:31 +0100
From: Kurt Kanzenbach <kurt@...utronix.de>
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>,
Jacob Keller <jacob.e.keller@...el.com>,
Gerhard Engleder <gerhard@...leder-embedded.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 Thu Jan 26 2023, 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.
Same for hellcreek. It has 8 TCs and the 1:1 mapping is used. So,
Acked-by: Kurt Kanzenbach <kurt@...utronix.de> # hellcreek
Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)
Powered by blists - more mailing lists