> Subject: Re: [PATCH 3/3] net/ice: fix Rx queue count reporting after TM > commit > > On Fri, Sep 04, 2026 at 10:51:39AM +0000, Ciara Loftus wrote: > > Currently, ice_dev_info_get() assigns the value of `vsi->nb_qps` to both > > `max_rx_queues` and `max_tx_queues`. > > > > After a Tx scheduler hierarchy is committed, the value of nb_qps may grow > > to reflect the VSI's larger Tx scheduler capacity. However the Tx scheduler > > hierarchy change has no effect on the VSI's Rx queue allocation, > > which stays fixed at its original size for the life of the port. An > > application can then request more Rx queues than the VSI's actual Rx > > resources support when the inflated nb_qps is assigned to `max_rx_queues`. > > > > `vsi->nb_qps` also feeds `ice_vsi_disable_queues_intr()`, which clears > > both Rx and Tx queue interrupt registers by absolute queue index on > > every port stop. Once `nb_qps` grows past the VSI's fixed queue window, > > this can clear interrupt registers belonging to a different VSI. > > > > Fix this by introducing `vsi->nb_tm_qps` to track the Tx scheduler > > Just a nit on naming here. For the tm block it doesn't deal with > queue-pairs so much as Tx queues, so the variable should probably be named > nb_tm_txqs instead.
+1 > > However, that opens a wider renaming question - rather than tracking a > generic nb_qps and nb_tm_qps(nb_tm_txqs), might it be better to have vsi > variables separately called "nb_rxqs" and "nb_txqs" and ignore the whole > "tm" part of it? I think that makes sense. I'll add that change as a fourth patch and you can see what you think. nb_qps is used in a few different places in the driver, mostly on init paths, so there is a little bit of churn. > > > capacity as it grows, leaving `vsi->nb_qps` as the VSI's fixed > > queue allocation for the life of the port. `ice_vsi_disable_queues_intr()` > > is switched to `nb_used_qps`, which already tracks the actually configured > > queue count. > >
