kernel/drivers/net/ethernet/intel/igc/igc_ethtool.c, branch linux-6.18.y

igc: Restore default Qbv schedule when changing channels

2026-01-30T09:32:10Z

[ Upstream commit 41a9a6826f20a524242a6c984845c4855f629841 ] The Multi-queue Priority (MQPRIO) and Earliest TxTime First (ETF) offloads utilize the Time Sensitive Networking (TSN) Tx mode. This mode is always coupled to IEEE 802.1Qbv time aware shaper (Qbv). Therefore, the driver sets a default Qbv schedule of all gates opened and a cycle time of 1s. This schedule is set during probe. However, the following sequence of events lead to Tx issues: - Boot a dual core system igc_probe(): igc_tsn_clear_schedule(): -> Default Schedule is set Note: At this point the driver has allocated two Tx/Rx queues, because there are only two CPUs. - ethtool -L enp3s0 combined 4 igc_ethtool_set_channels(): igc_reinit_queues() -> Default schedule is gone, per Tx ring start and end time are zero - tc qdisc replace dev enp3s0 handle 100 parent root mqprio \ num_tc 4 map 3 3 2 2 0 1 1 1 3 3 3 3 3 3 3 3 \ queues 1@0 1@1 1@2 1@3 hw 1 igc_tsn_offload_apply(): igc_tsn_enable_offload(): -> Writes zeros to IGC_STQT(i) and IGC_ENDQT(i), causing Tx to stall/fail Therefore, restore the default Qbv schedule after changing the number of channels. Furthermore, add a restriction to not allow queue reconfiguration when TSN/Qbv is enabled, because it may lead to inconsistent states. Fixes: c814a2d2d48f ("igc: Use default cycle 'start' and 'end' values for queues") Signed-off-by: Kurt Kanzenbach Reviewed-by: Aleksandr Loktionov Tested-by: Avigail Dahan Acked-by: Vinicius Costa Gomes Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin

igc: use EOPNOTSUPP instead of ENOTSUPP in igc_ethtool_get_sset_count()

2025-10-28T19:49:59Z

igc_ethtool_get_sset_count() returns -ENOTSUPP when a given stringset is not supported, causing userland programs to get "Unknown error 524". Since EOPNOTSUPP should be used when error is propagated to userland, return -EOPNOTSUPP instead of -ENOTSUPP. Fixes: 36b9fea60961 ("igc: Add support for statistics") Signed-off-by: Kohei Enju Reviewed-by: Aleksandr Loktionov Signed-off-by: Tony Nguyen

igc: power up the PHY before the link test

2025-10-28T19:49:59Z

The current implementation of the igc driver doesn't power up the PHY before the link test in igc_ethtool_diag_test(), causing the link test to always report FAIL when admin state is down and the PHY is consequently powered down. To test the link state regardless of admin state, power up the PHY before the link test in the offline test path. After the link test, the original PHY state is restored by igc_reset(), so additional code which explicitly restores the original state is not necessary. Note that this change is applied only for the offline test path. This is because in the online path we shouldn't interrupt normal networking operation and powering up the PHY and restoring the original state would interrupt that. This implementation also uses igc_power_up_phy_copper() without checking the media type, since igc devices are currently only copper devices and the function is called in other places without checking the media type. Furthermore, the powering up is on a best-effort basis, that is, we don't handle failures of powering up (e.g. bus error) and just let the test report FAIL. Tested on Intel Corporation Ethernet Controller I226-V (rev 04) with cable connected and link available. Set device down and do ethtool test. # ip link set dev enp0s5 down Without patch: # ethtool --test enp0s5 The test result is FAIL The test extra info: Register test (offline) 0 Eeprom test (offline) 0 Interrupt test (offline) 0 Loopback test (offline) 0 Link test (on/offline) 1 With patch: # ethtool --test enp0s5 The test result is PASS The test extra info: Register test (offline) 0 Eeprom test (offline) 0 Interrupt test (offline) 0 Loopback test (offline) 0 Link test (on/offline) 0 Fixes: f026d8ca2904 ("igc: add support to eeprom, registers and link self-tests") Signed-off-by: Kohei Enju Reviewed-by: Vitaly Lifshits Tested-by: Avigail Dahan Signed-off-by: Tony Nguyen

eth: intel: use vmalloc_array() to simplify code

2025-08-19T00:49:51Z

Remove array_size() calls and replace vmalloc() with vmalloc_array() to simplify the code and maintain consistency with existing kmalloc_array() usage. vmalloc_array() is also optimized better, resulting in less instructions being used. Signed-off-by: Qianfeng Rong Link: https://patch.msgid.link/20250816090659.117699-2-rongqianfeng@vivo.com Signed-off-by: Jakub Kicinski

igc: Add wildcard rule support to ethtool NFC using Default Queue

2025-07-18T16:02:28Z

Introduce support for a lowest priority wildcard (catch-all) rule in ethtool's Network Flow Classification (NFC) for the igc driver. The wildcard rule directs all unmatched network traffic, including traffic not captured by Receive Side Scaling (RSS), to a specified queue. This functionality utilizes the Default Queue feature available in I225/I226 hardware. The implementation has been validated on Intel ADL-S systems with two back-to-back connected I226 network interfaces. Testing Procedure: 1. On the Device Under Test (DUT), verify the initial statistic: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 0 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 2. From the Link Partner, send 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 3. On the DUT, verify the packet reception on Queue 0: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 0 4. On the DUT, add a wildcard rule to route all packets to Queue 3: $ sudo ethtool -N enp1s0 flow-type ether queue 3 5. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 6. Now, packets are routed to Queue 3 by the wildcard (Default Queue) rule: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 0 rx_queue_2_packets: 0 rx_queue_3_packets: 10 7. On the DUT, add a EtherType rule to route ARP packet to Queue 1: $ sudo ethtool -N enp1s0 flow-type ether proto 0x0806 queue 1 8. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 9. Now, packets are routed to Queue 1 by the EtherType rule because it is higher priority than the wildcard (Default Queue) rule: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 10 rx_queue_1_packets: 10 rx_queue_2_packets: 0 rx_queue_3_packets: 10 10. On the DUT, delete all the NFC rules: $ sudo ethtool -N enp1s0 delete 63 $ sudo ethtool -N enp1s0 delete 64 11. From the Link Partner, send another 10 ARP packets: $ arping -c 10 -I enp170s0 169.254.1.2 12. Now, packets are routed to Queue 0 because the value of Default Queue is reset back to 0: $ ethtool -S enp1s0 | grep rx_q.*packets rx_queue_0_packets: 20 rx_queue_1_packets: 10 rx_queue_2_packets: 0 rx_queue_3_packets: 10 Reviewed-by: Kurt Kanzenbach Co-developed-by: Blanco Alcaine Hector Signed-off-by: Blanco Alcaine Hector Signed-off-by: Song Yoong Siang Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

Merge branch 'intel-next-queue-1GbE'

2025-06-17T13:04:05Z

Tony Nguyen says: ==================== Faizal Rahim says: MAC Merge support for frame preemption was previously added for igc: https://lore.kernel.org/netdev/20250418163822.3519810-1-anthony.l.nguyen@intel.com/ This series builds on that work and adds support for: - Harmonizing taprio and mqprio queue priority behavior, based on past discussions and suggestions: https://lore.kernel.org/all/20250214102206.25dqgut5tbak2rkz@skbuf/ - Enabling preemptible queue support for both taprio and mqprio, with priority harmonization as a prerequisite. Patch organization: - Patches 1-3: Preparation work for patches 6 and 7 - Patches 4-5: Queue priority harmonization - Patches 6-7: Add preemptible queue support ==================== Link: https://patch.msgid.link/20250611180314.2059166-1-anthony.l.nguyen@intel.com Signed-off-by: Paolo Abeni

eth: igc: migrate to new RXFH callbacks

2025-06-17T01:14:52Z

Migrate to new callbacks added by commit 9bb00786fc61 ("net: ethtool: add dedicated callbacks for getting and setting rxfh fields"). Reviewed-by: Aleksandr Loktionov Reviewed-by: Joe Damato Reviewed-by: Tony Nguyen Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20250614180907.4167714-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

igc: add private flag to reverse TX queue priority in TSN mode

2025-06-11T17:06:24Z

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 [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 Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: add support to get frame preemption statistics via ethtool

2025-04-18T16:17:14Z

Implemented "ethtool --include-statistics --show-mm" callback for IGC. Tested preemption scenario to check preemption statistics: 1) Trigger verification handshake on both boards: $ sudo ethtool --set-mm enp1s0 pmac-enabled on $ sudo ethtool --set-mm enp1s0 tx-enabled on $ sudo ethtool --set-mm enp1s0 verify-enabled on 2) Set preemptible or express queue in taprio for tx board: $ sudo tc qdisc replace dev enp1s0 parent root handle 100 taprio \ num_tc 4 map 3 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \ queues 1@0 1@1 1@2 1@3 base-time 0 sched-entry S F 100000 \ fp E E P P 3) Send large size packets on preemptible queue 4) Send small size packets on express queue to preempt packets in preemptible queue 5) Show preemption statistics on the receiving board: $ ethtool --include-statistics --show-mm enp1s0 MAC Merge layer state for enp1s0: pMAC enabled: on TX enabled: on TX active: on TX minimum fragment size: 64 RX minimum fragment size: 60 Verify enabled: on Verify time: 128 Max verify time: 128 Verification status: SUCCEEDED Statistics: MACMergeFrameAssErrorCount: 0 MACMergeFrameSmdErrorCount: 0 MACMergeFrameAssOkCount: 511 MACMergeFragCountRx: 764 MACMergeFragCountTx: 0 MACMergeHoldCount: 0 Co-developed-by: Vinicius Costa Gomes Signed-off-by: Vinicius Costa Gomes Co-developed-by: Chwee-Lin Choong Signed-off-by: Chwee-Lin Choong Reviewed-by: Vladimir Oltean Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen

igc: add support to get MAC Merge data via ethtool

2025-04-18T16:17:14Z

Implement "ethtool --show-mm" callback for IGC. Tested with command: $ ethtool --show-mm enp1s0. MAC Merge layer state for enp1s0: pMAC enabled: on TX enabled: on TX active: on TX minimum fragment size: 64 RX minimum fragment size: 60 Verify enabled: on Verify time: 128 Max verify time: 128 Verification status: SUCCEEDED Verified that the fields value are retrieved correctly. Reviewed-by: Vladimir Oltean Signed-off-by: Faizal Rahim Tested-by: Mor Bar-Gabay Signed-off-by: Tony Nguyen