[PATCH 3/3] net/ice: fix Rx queue count reporting after TM commit

[Loftus, Ciara]

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