From: Stephen Hemminger <stephen@networkplumber.org>
To: KAVYA AV <kavyax.a.v@intel.com>
Cc: dev@dpdk.org, bruce.richardson@intel.com,
aman.deep.singh@intel.com, vladimir.medvedkin@intel.com,
shaiq.wani@intel.com, stable@dpdk.org
Subject: Re: [PATCH v2] app/testpmd: fix DCB queue allocation for VMDq devices
Date: Mon, 23 Mar 2026 16:51:55 -0700 [thread overview]
Message-ID: <20260323165155.7f7d7bd9@phoenix.local> (raw)
In-Reply-To: <20260316055255.2134834-1-kavyax.a.v@intel.com>
On Mon, 16 Mar 2026 05:52:55 +0000
KAVYA AV <kavyax.a.v@intel.com> wrote:
> When using DCB mode with VT disabled and requesting more queues than
> traffic classes (e.g., rxq=64 with 8 TCs), testpmd crashes with null
> pointer errors because it artificially limits queue allocation to
> num_tcs.
>
> For VMDq devices, use device-specific queue count (nb_rx_queues/
> nb_tx_queues) instead of limiting to num_tcs. This allows VMDq devices
> to utilize their full queue capacity while maintaining compatibility
> with non VMDq devices.
>
> Fixes null pointer dereference when queue structures are accessed
> beyond the allocated range.
>
> Fixes: 2169699b15fc ("app/testpmd: add queue restriction in DCB command")
> Cc: stable@dpdk.org
>
> Signed-off-by: KAVYA AV <kavyax.a.v@intel.com>
> ---
It makes sense to do this but AI review raised a number of issues:
Error: Wrong field — nb_rx_queues reflects the previous configure, not the device's DCB queue capacity
The patch changes the vmdq_pool_base > 0 path from num_tcs to dev_info.nb_rx_queues / dev_info.nb_tx_queues. However, dev_info.nb_rx_queues is the configured queue count from the rte_eth_dev_configure() call that happened earlier in this same function (line 4413: rte_eth_dev_configure(pid, nb_rxq, nb_rxq, &port_conf)). So dev_info.nb_rx_queues just reflects whatever nb_rxq was before entering this block — it is not the device's inherent DCB queue capacity.
If nb_rxq was previously set to 64 by the user (rxq=64), then after configure dev_info.nb_rx_queues will be 64, and this code sets nb_rxq = 64 — which is circular. It does avoid the crash from using num_tcs (which could be too small), but it doesn't set the queue count to a value derived from the device's VMDq/DCB capability. Compare with the DCB_VT_ENABLED branch just above, which uses dev_info.nb_rx_queues only when max_vfs > 0 because the VF driver legitimately constrains nb_rx_queues during configure.
For the VT_DISABLED + vmdq_pool_base > 0 case, the intent is to limit queues to those available to the PF (since VMDq pools consume some). The original num_tcs was an approximation; nb_rx_queues is another approximation that happens to be the user's requested count echoed back. Consider whether the correct value should be derived from vmdq_queue_base or vmdq_queue_num fields instead, which describe the actual PF/VMDq queue layout.
Warning: Comment is misleading
The added comment says "Use device queue counts to prevent null pointer errors" but dev_info.nb_rx_queues is the configured count, not a device-intrinsic limit. The comment should describe why this value is appropriate for the VMDq-with-pool-base case.
next prev parent reply other threads:[~2026-03-23 23:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 10:15 [PATCH] app/testpmd: fix DCB queue allocation for VMDq devices KAVYA AV
2026-03-13 21:00 ` Stephen Hemminger
2026-03-16 5:52 ` [PATCH v2] " KAVYA AV
2026-03-23 23:51 ` Stephen Hemminger [this message]
2026-03-24 10:05 ` [PATCH v3] " KAVYA AV
2026-03-24 15:46 ` Stephen Hemminger
2026-03-26 11:22 ` A V, KavyaX
2026-04-09 6:43 ` [PATCH v4] " KAVYA AV
2026-04-12 16:20 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260323165155.7f7d7bd9@phoenix.local \
--to=stephen@networkplumber.org \
--cc=aman.deep.singh@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=kavyax.a.v@intel.com \
--cc=shaiq.wani@intel.com \
--cc=stable@dpdk.org \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.