Re: [PATCH] app/testpmd: fix stale queue-count check order

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri,  4 Sep 2026 13:38:42 +0000
Ciara Loftus <ciara.loftus@intel.com> wrote:

> Currently, when setting the number of queues via `port config all txq/rxq`,
> testpmd validates the requested queue count against a device's current
> queue-count limits, then rebuilds the forwarding stream configuration
> before refreshing each port's cached device information. The forwarding
> stream setup step re-checks the requested queue count against that cache,
> so it can still reject a value that was just accepted if the cached
> limits are older than the freshly queried ones.
> 
> This is not observable while a port's queue-count limits stay fixed
> for its lifetime. It becomes visible whenever a PMD's reported
> `max_rx_queues`/`max_tx_queues` change after the port was first probed,
> for example when a driver recomputes queue capacity in response to a
> traffic management (`rte_tm`) hierarchy commit. The stale cached values
> then no longer match what the device currently reports, so a queue count
> that is actually valid can be wrongly rejected.
> 
> Fix it by refreshing the cached device information before rebuilding
> the forwarding stream configuration, so both checks operate on the same,
> current queue-count limits.
> 
> Fixes: 0c0db76f42ed ("app/testpmd: separate forward config setup from display")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>

Applied to next-net, but rewrote the overly wordy commit message.
I chopped it down to two sentences.

You need to ask AI to generate concise commit messages or you
get three paragraphs for one line change like this.

Also, I don't think this needs to go to stable. It is a theoretical problem
not something actually reproducible.