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

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

[Ciara Loftus]

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>
---
 app/test-pmd/cmdline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 10ee7c5179..95a4ebfb96 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2010,10 +2010,10 @@ cmd_config_rx_tx_parsed(void *parsed_result,
 		return;
 	}
 
-	fwd_config_setup();
-
 	init_port_config();
 
+	fwd_config_setup();
+
 	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
 }
 
-- 
2.43.0

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

[Stephen Hemminger]

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.