On Fri, 4 Sep 2026 13:38:42 +0000
Ciara Loftus <[email protected]> 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: [email protected]
>
> Signed-off-by: Ciara Loftus <[email protected]>
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.
