[iwl-next,v3,5/7] igc: add private flag to reverse TX queue priority in TSN mode

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(-)

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>