Kurt Kanzenbach <[email protected]> writes: > On Wed Nov 12 2025, Vinicius Costa Gomes wrote: >> Hi, >> >> Kurt Kanzenbach <[email protected]> writes: >> >>> The MQPRIO (and ETF) offload utilizes the TSN Tx mode. This mode is always >>> coupled to 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 >>> 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 CPU(s). >>> >>> - 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) -> Boom >>> >>> Therefore, restore the default Qbv schedule after changing the amount of >>> channels. >>> >> >> Couple of questions: >> - Would it make sense to mark this patch as a fix? > > This only happens if a user uses ETF or MQPRIO and a dual/single core > system. So I didn't see the need to mark it as a fix. >
I still think this is fix material. People can always run stuff in VMs, and it makes it easier to have single/dual core systems. >> >> - What would happen if the user added a Qbv schedule (not the default >> one) and then changed the number of queues? My concern is that 'tc >> qdisc' would show the custom user schedule and the hardware would be >> "running" the default schedule, this inconsistency is not ideal. In >> any case, it would be a separate patch. > > Excellent point. Honestly I'm not sure what to expect when changing the > number of queues after a user Qbv schedule is added. For MQPRIO we added > a restriction [1] especially for that case. I'm leaning towards the same > solution here. What do you think? Sounds great. Avoiding getting into inconsistent states is better than trying to fix it later. > > Thanks, > Kurt > > [1] - > https://elixir.bootlin.com/linux/v6.18-rc5/source/drivers/net/ethernet/intel/igc/igc_ethtool.c#L1564 Cheers, -- Vinicius
