All of lore.kernel.org
 help / color / mirror / Atom feed
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 v3] app/testpmd: fix DCB queue allocation for VMDq devices
Date: Tue, 24 Mar 2026 08:46:55 -0700	[thread overview]
Message-ID: <20260324084655.6d22c7fc@phoenix.local> (raw)
In-Reply-To: <20260324100500.2516672-1-kavyax.a.v@intel.com>

On Tue, 24 Mar 2026 10:05:00 +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 actual VMDq queue layout (vmdq_queue_num) 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>
> ---

I can't follow all the stuff here, is rather complex and esoteric case.
So did AI review.

The feedback from AI raised some questions (the I here is AI not me):


The basic idea of using dynamic VMDq queue info instead of limiting
to num_tcs is right -- the current code clearly crashes when more
queues are requested than traffic classes.

However, I'm not convinced vmdq_queue_num is the correct value here.
This code path is DCB-only (VT disabled) on a device with
vmdq_pool_base > 0, which in practice means i40e. In that case
vmdq_queue_num is the total VMDq pool queue count
(vmdq_nb_qps * max_nb_vmdq_vsi), but with VT disabled the PF queues
are what's used for DCB, not the VMDq pool queues. The PF queue count
would be max_rx_queues - vmdq_queue_num. Using the VMDq count here
could over-allocate or misconfigure queues in DCB-only mode.

Can you explain why vmdq_queue_num is the right value rather than
the PF queue count? Or test what happens when this value exceeds
what the hardware supports in DCB-only mode?

Minor: the prose line "Fixes null pointer dereference when queue
structures are accessed beyond the allocated range." reads as a
sentence fragment. Fold it into the preceding paragraph or drop it
since the Fixes tag already identifies what's being fixed.


  reply	other threads:[~2026-03-24 15:47 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
2026-03-24 10:05 ` [PATCH v3] " KAVYA AV
2026-03-24 15:46   ` Stephen Hemminger [this message]
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=20260324084655.6d22c7fc@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.