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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <874iqxng33.fsf@jax.kurt.home>
Date: Fri, 14 Nov 2025 10:01:04 +0100
From: Kurt Kanzenbach <kurt@...utronix.de>
To: Vinicius Costa Gomes <vinicius.gomes@...el.com>, Tony Nguyen
 <anthony.l.nguyen@...el.com>, Przemek Kitszel
 <przemyslaw.kitszel@...el.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Sebastian Andrzej
 Siewior <bigeasy@...utronix.de>, intel-wired-lan@...ts.osuosl.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH iwl-next] igc: Restore default Qbv schedule when
 changing channels

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

Fair enough.

>
>>>
>>>  - 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.

Jup. I'll wait a bit for further comments and then send a v2 with your
and Aleksandr's suggestions addressed.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)