From: Stephen Hemminger <stephen@networkplumber.org>
To: Dariusz Sosnowski <dsosnowski@nvidia.com>
Cc: Aman Singh <aman.deep.singh@intel.com>, <dev@dpdk.org>,
Thomas Monjalon <thomas@monjalon.net>,
Raslan Darawsheh <rasland@nvidia.com>,
"Adrian Schollmeyer" <a.schollmeyer@syseleven.de>
Subject: Re: [PATCH v2 1/2] app/testpmd: assign share group dynamically
Date: Wed, 25 Mar 2026 09:49:20 -0700 [thread overview]
Message-ID: <20260325094920.4e086ef0@phoenix.local> (raw)
In-Reply-To: <20260324165657.23945-2-dsosnowski@nvidia.com>
On Tue, 24 Mar 2026 17:56:56 +0100
Dariusz Sosnowski <dsosnowski@nvidia.com> wrote:
> Testpmd exposes "--rxq-share=[N]" parameter which controls
> sharing Rx queues. Before this patch logic was that either:
>
> - all queues were assigned to the same share group
> (when N was not passed),
> - or ports were grouped in subsets of N ports,
> each subset got different share group index.
>
> 2nd option did not work well with dynamic representor probing,
> where new representors would be assigned to new share group.
>
> This patch changes the logic in testpmd to dynamically
> assign share group index. Each unique switch and Rx domain
> will get different share group.
>
> Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> ---
AI review found that the option definition still expects arg.
Warning: Option definition still uses OPTIONAL_ARG but argument is now ignored.
The --rxq-share parameter definition at line 354 in
parameters.c still uses OPTIONAL_ARG(TESTPMD_OPT_RXQ_SHARE) (which maps
to optional_argument in getopt), but the parsing now unconditionally
sets rxq_share = 1 and ignores optarg. If a user passes --rxq-share=5,
the value is silently discarded. The option definition should be
changed to NO_ARG(TESTPMD_OPT_RXQ_SHARE) to match the new behavior, and
the documentation now correctly documents it as a bare flag.
Warning: share_group_slots entries are never cleared on port removal.
The share_group_slots[] array grows as new (domain_id, rx_domain) pairs
are seen, but entries are never removed when ports are hot-unplugged or
closed. Over many hotplug cycles with distinct domain IDs, slots could
fill up. In practice this is bounded by RTE_MAX_ETHPORTS (default 32)
so it is unlikely to be a real problem, but an RTE_ASSERT will fire if
it does overflow — worth a comment noting this limitation.
Info: Documentation grammar nit.
In run_app.rst, "This engine does Rx only and update stream statistics accordingly" — "update" should be "updates".
next prev parent reply other threads:[~2026-03-25 16:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 12:37 [PATCH 0/2] app/testpmd: assign share group dynamically Dariusz Sosnowski
2026-03-24 12:37 ` [PATCH 1/2] " Dariusz Sosnowski
2026-03-24 15:15 ` Stephen Hemminger
2026-03-25 16:45 ` Stephen Hemminger
2026-03-24 12:37 ` [PATCH 2/2] app/testpmd: revert switch domain mismatch check Dariusz Sosnowski
2026-03-24 15:17 ` Stephen Hemminger
2026-03-24 16:56 ` [PATCH v2 0/2] app/testpmd: assign share group dynamically Dariusz Sosnowski
2026-03-24 16:56 ` [PATCH v2 1/2] " Dariusz Sosnowski
2026-03-25 16:49 ` Stephen Hemminger [this message]
2026-03-25 18:06 ` Dariusz Sosnowski
2026-03-25 16:50 ` Stephen Hemminger
2026-03-25 18:12 ` Dariusz Sosnowski
2026-03-24 16:56 ` [PATCH v2 2/2] app/testpmd: revert switch domain mismatch check Dariusz Sosnowski
2026-03-25 18:02 ` [PATCH v3 0/2] app/testpmd: assign share group dynamically Dariusz Sosnowski
2026-03-25 18:02 ` [PATCH v3 1/2] " Dariusz Sosnowski
2026-03-25 18:51 ` Stephen Hemminger
2026-03-25 19:11 ` Dariusz Sosnowski
2026-03-25 18:02 ` [PATCH v3 2/2] app/testpmd: revert switch domain mismatch check Dariusz Sosnowski
2026-03-25 19:09 ` [PATCH v4 0/2] app/testpmd: assign share group dynamically Dariusz Sosnowski
2026-03-25 19:09 ` [PATCH v4 1/2] " Dariusz Sosnowski
2026-03-25 19:09 ` [PATCH v4 2/2] app/testpmd: revert switch domain mismatch check Dariusz Sosnowski
2026-03-25 20:16 ` [PATCH v4 0/2] app/testpmd: assign share group dynamically 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=20260325094920.4e086ef0@phoenix.local \
--to=stephen@networkplumber.org \
--cc=a.schollmeyer@syseleven.de \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=rasland@nvidia.com \
--cc=thomas@monjalon.net \
/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.