On Thu Nov 13 2025, Vinicius Costa Gomes wrote: > 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.
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
signature.asc
Description: PGP signature
