Re: [Intel-wired-lan] [PATCH iwl-next] igc: Restore default Qbv schedule when changing channels

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Kurt Kanzenbach <kurt@linutronix.de> writes:

> On Wed Nov 12 2025, Vinicius Costa Gomes wrote:
>> Hi,
>>
>> Kurt Kanzenbach <kurt@linutronix.de> 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