Re: [Intel-wired-lan] [PATCH iwl-next v3 5/7] igc: add private flag to reverse TX queue priority in TSN mode

[Mor Bar-Gabay <morx.bar.gabay@intel.com>]

On 19/05/2025 10:19, Abdul Rahim, Faizal wrote:
> From: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> 
> By default, igc assigns TX hw queue 0 the highest priority and queue 3
> the lowest. This is opposite of most NICs, where TX hw queue 3 has the
> highest priority and queue 0 the lowest.
> 
> mqprio in igc already uses TX arbitration unconditionally to reverse TX
> queue priority when mqprio is enabled. The TX arbitration logic does not
> require a private flag, because mqprio was added recently and no known
> users depend on the default queue ordering, which differs from the typical
> convention.
> 
> taprio does not use TX arbitration, so it inherits the default igc TX
> queue priority order. This causes tc command inconsistencies when
> configuring frame preemption with taprio compared to mqprio in igc.
> Other tc command inconsistencies and configuration issues already exist
> when using taprio on igc compared to other network controllers. These
> issues are described in a later section.
> 
> To harmonize TX queue priority behavior between taprio and mqprio, and
> to fix these issues without breaking long-standing taprio use cases,
> this patch adds a new private flag, called reverse-tsn-txq-prio, to
> reverse the TX queue priority. It makes queue 3 the highest and queue 0
> the lowest, reusing the TX arbitration logic already used by mqprio.
> 
> Users must set the private flag when enabling frame preemption with
> taprio to follow the standard convention. Doing so promotes adoption of
> the correct priority model for new features while preserving
> compatibility with legacy configurations.
> 
> This new private flag addresses:
> 
> 1.  Non-standard socket → tc → TX hw queue mapping for taprio in igc
> 
> Without the private flag:
> - taprio maps (socket → tc → TX hardware queue) differently on igc
>    compared to other network controllers
> - On igc, mqprio maps tc differently from taprio, since mqprio already
>    uses TX arbitration
> 
> The following examples compare taprio configuration on igc and other
> network controllers:
> a)  On other NICs (TX hw queue 3 is highest priority):
>      taprio num_tc 4 map 0 1 2 3 .... \
>      queues 1@0 1@1 1@2 1@3
> 
>      Mapping translates to:
>      socket 0 → tc 0 → queue 0
>      socket 3 → tc 3 → queue 3
> 
>      This is the normal mapping that respects the standard convention:
>      higher socket number → higher tc -> higher priority TX hw queue
> 
> b)  On igc (TX hw queue 0 is highest priority by default):
>      taprio num_tc 4 map 3 2 1 0 .... \
>      queues 1@0 1@1 1@2 1@3
> 
>      Mapping translates to:
>      socket 0 → tc 3 → queue 3
>      socket 3 → tc 0 → queue 0
> 
>      This igc tc mapping example is based on Intel's TSN validation test
>      case, where a higher socket priority maps to a higher priority queue.
>      It respects the mapping:
>        higher socket number -> higher priority TX hw queue
>      but breaks the expected ordering:
>        higher tc -> higher priority TX hw queue
>      as defined in [Ref1]. This custom mapping complicates common taprio
>      setup across NICs.
> 
> 2.  Non-standard frame preemption mapping for taprio in igc
> 
> Without the private flag:
> - Compared to other network controllers, taprio on igc must flip the
>    expected fp sequence, since express traffic is expected to map to the
>    highest priority queue and preemptible traffic to lower ones
> - On igc, frame preemption configuration for mqprio differs from taprio,
>    since mqprio already uses TX arbitration
> 
> The following examples compare taprio frame preemption configuration on
> igc and other network controllers:
> a)  On other NICs (TX hw queue 3 is highest priority):
>      taprio num_tc 4 map ..... \
>      queues 1@0 1@1 1@2 1@3 \
>      fp P P P E
> 
>      Mapping translates to:
>      tc0, tc1, tc2 → preemptible → queue 0, 1, 2
>      tc3           → express     → queue 3
> 
>      This is the normal mapping that respects the standard convention:
>      higher tc -> express traffic -> higher priority TX hw queue
>      lower tc  -> preemptible traffic -> lower priority TX hw queue
> 
> b)  On igc (TX hw queue 0 is highest priority by default):
>      taprio num_tc 4 map ...... \
>      queues 1@0 1@1 1@2 1@3 \
>      fp E P P P
> 
>      Mapping translates to:
>      tc0           → express     → queue 0
>      tc1, tc2, tc3 → preemptible → queue 1, 2, 3
> 
>      This inversion respects the mapping of:
>        express traffic -> higher priority TX hw queue
>      but breaks the expected ordering:
>        higher tc -> express traffic
>      as defined in [Ref1] where higher tc indicates higher priority. In
>      this case, the lower tc0 is assigned to express traffic. This custom
>      mapping further complicates common preemption setup across NICs.
> 
> Tests were performed on taprio with the following combinations, where
> two apps send traffic simultaneously on different queues:
> 
>    Private Flag   Traffic Sent By           Traffic Sent By
>    ----------------------------------------------------------------
>    enabled        iperf3 (queue 3)          iperf3 (queue 0)
>    disabled       iperf3 (queue 0)          iperf3 (queue 3)
>    enabled        iperf3 (queue 3)          real-time app (queue 0)
>    disabled       iperf3 (queue 0)          real-time app (queue 3)
>    enabled        real-time app (queue 3)   iperf3 (queue 0)
>    disabled       real-time app (queue 0)   iperf3 (queue 3)
>    enabled        real-time app (queue 3)   real-time app (queue 0)
>    disabled       real-time app (queue 0)   real-time app (queue 3)
> 
> Private flag is controlled with:
>   ethtool --set-priv-flags enp1s0 reverse-tsn-txq-prio <on|off>
> 
> [Ref1]
> IEEE 802.1Q clause 8.6.8 Transmission selection:
> "For a given Port and traffic class, frames are selected from the
> corresponding queue for transmission if and only if:
> ...
> b) For each queue corresponding to a numerically higher value of traffic
> class supported by the Port, the operation of the transmission selection
> algorithm supported by that queue determines that there is no frame
> available for transmission."
> 
> Reviewed-by: Simon Horman <horms@kernel.org>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> ---
>   drivers/net/ethernet/intel/igc/igc.h         |  1 +
>   drivers/net/ethernet/intel/igc/igc_ethtool.c | 12 ++++++++++--
>   drivers/net/ethernet/intel/igc/igc_main.c    |  3 ++-
>   drivers/net/ethernet/intel/igc/igc_tsn.c     |  3 ++-
>   4 files changed, 15 insertions(+), 4 deletions(-)
> 
Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>