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: [email protected]
Signed-off-by: Ciara Loftus <[email protected]>
---
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
