From: Stephen Hemminger <stephen@networkplumber.org>
To: <pbhagavatula@marvell.com>
Cc: <mb@smartsharesystems.com>, <jerinj@marvell.com>,
Wisam Jaddo <wisamm@nvidia.com>,
Aman Singh <aman.deep.singh@intel.com>,
Chas Williams <3chas3@gmail.com>,
"Min Hu (Connor)" <humin29@huawei.com>,
Akhil Goyal <gakhil@marvell.com>,
Anoob Joseph <anoobj@marvell.com>,
Nicolas Chautru <nicolas.chautru@intel.com>,
David Hunt <david.hunt@intel.com>,
Chengwen Feng <fengchengwen@huawei.com>,
Kevin Laatz <kevin.laatz@intel.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
Konstantin Ananyev <konstantin.ananyev@huawei.com>,
Radu Nicolau <radu.nicolau@intel.com>,
Tomasz Kantecki <tomasz.kantecki@intel.com>,
Fan Zhang <fanzhang.oss@gmail.com>,
Sunil Kumar Kori <skori@marvell.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Sivaprasad Tummala <sivaprasad.tummala@amd.com>,
Jingjing Wu <jingjing.wu@intel.com>,
Volodymyr Fialko <vfialko@marvell.com>,
Cristian Dumitrescu <cristian.dumitrescu@intel.com>,
John McNamara <john.mcnamara@intel.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>,
Chenbo Xia <chenbox@nvidia.com>, <dev@dpdk.org>
Subject: Re: [PATCH 2/2] examples: use default mbuf burst size
Date: Sat, 21 Feb 2026 08:26:46 -0800 [thread overview]
Message-ID: <20260221082646.4ec49f29@phoenix.local> (raw)
In-Reply-To: <20260220230745.26418-2-pbhagavatula@marvell.com>
On Sat, 21 Feb 2026 04:37:44 +0530
<pbhagavatula@marvell.com> wrote:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Replace hardcoded burst sizes with RTE_MBUF_BURST_SIZE_DEFAULT
> to adapt to platform-specific optimal burst sizes.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
This is way to broad. See deeper AI analysis for all the places
this patch is over stepping...
Should only touch examples, and never change the MAX values.
It should not change any drivers.
-----
Patch 2/2: examples: use default mbuf burst size
Error: Semantic mismatch — evt_options.vector_size set to burst size macro
In app/test-eventdev/evt_options.c:

c
- opt->vector_size = 64;
+ opt->vector_size = RTE_MBUF_BURST_SIZE_DEFAULT;
The original hardcoded value of 64 for vector_size is an event vector size, not an mbuf burst size. Event vector sizes and mbuf burst sizes serve different purposes — event vectors aggregate events for batch processing and can legitimately be larger than the Rx/Tx burst size. Replacing 64 with RTE_MBUF_BURST_SIZE_DEFAULT (which defaults to 32 in throughput mode) silently halves the default event vector size on all non-CN10K platforms. This is a functional regression that could degrade event-mode throughput. The original value should remain 64, or a separate RTE_EVENT_VECTOR_SIZE_DEFAULT macro should be introduced.
Error: MAX_PKT_BURST_VEC reduced from 256 to burst default
In examples/ipsec-secgw/ipsec-secgw.h:

c
-#define MAX_PKT_BURST_VEC 256
+#define MAX_PKT_BURST_VEC RTE_MBUF_BURST_SIZE_DEFAULT
MAX_PKT_BURST_VEC was intentionally set to 256 for vectorized IPsec processing, which processes packets in large vectorized batches. Reducing it to 32 (the default throughput burst size) is a significant behavioral change that will likely hurt vectorized IPsec performance. This macro also feeds into the MAX_PKTS calculation immediately below it, so the reduction cascades. This should either keep 256 or use a separate vector-specific configuration.
Error: MAX_PKT_BURST and DEF_PKT_BURST collapsed to same value in bonding tests
In app/test/test_link_bonding_mode4.c:

c
-#define MAX_PKT_BURST (32)
-#define DEF_PKT_BURST (16)
+#define MAX_PKT_BURST (RTE_MBUF_BURST_SIZE_DEFAULT)
+#define DEF_PKT_BURST (RTE_MBUF_BURST_SIZE_DEFAULT)
Originally MAX_PKT_BURST (32) and DEF_PKT_BURST (16) were intentionally different values — the max is a buffer/array size limit and the default is the actual burst count used. Setting both to the same value means the test now always bursts at the maximum array size with no headroom. If any code path allocates MAX_PKT_BURST elements and bursts DEF_PKT_BURST, this distinction is lost. At minimum, DEF_PKT_BURST should remain smaller than MAX_PKT_BURST.
Similarly in app/test/test_link_bonding.c, the original DEF_PKT_BURST was 16, now it becomes RTE_MBUF_BURST_SIZE_DEFAULT (32), which equals MAX_PKT_BURST in some cases — same concern about losing the max/default distinction.
Warning: NTB_MAX_PKT_BURST and NTB_DFLT_PKT_BURST collapsed
In examples/ntb/ntb_fwd.c:

c
-#define NTB_MAX_PKT_BURST 32
-#define NTB_DFLT_PKT_BURST 32
+#define NTB_MAX_PKT_BURST RTE_MBUF_BURST_SIZE_DEFAULT
+#define NTB_DFLT_PKT_BURST RTE_MBUF_BURST_SIZE_DEFAULT
These were already the same value (32), so there's no regression today, but the intent of having separate MAX and DEFAULT macros is to allow them to diverge. Replacing both with the same configurable macro permanently ties them together. Consider using RTE_MBUF_BURST_SIZE_DEFAULT only for the default and keeping MAX as a separate (potentially larger) constant.
Warning: RTE_MBUF_F_RX_BURST_MAX / RTE_MBUF_F_TX_BURST_MAX naming confusion
In examples/qos_meter/main.c:

c
-#define RTE_MBUF_F_RX_BURST_MAX 32
-#define RTE_MBUF_F_TX_BURST_MAX 32
+#define RTE_MBUF_F_RX_BURST_MAX RTE_MBUF_BURST_SIZE_DEFAULT
+#define RTE_MBUF_F_TX_BURST_MAX RTE_MBUF_BURST_SIZE_DEFAULT
The RTE_MBUF_F_ prefix is reserved for mbuf flags (e.g., RTE_MBUF_F_RX_RSS_HASH). These macros are local to the example and not real mbuf flags, but this naming is confusing and was a pre-existing issue. Since this patch is already touching these lines, it would be a good opportunity to rename them to something like QOS_RX_BURST_MAX/QOS_TX_BURST_MAX to avoid namespace confusion.
Warning: PKT_ENQUEUE and PKT_DEQUEUE not updated in qos_sched
In examples/qos_sched/main.h:

c
#define MAX_PKT_RX_BURST RTE_MBUF_BURST_SIZE_DEFAULT
#define PKT_ENQUEUE 64
#define PKT_DEQUEUE 63
#define MAX_PKT_TX_BURST RTE_MBUF_BURST_SIZE_DEFAULT
MAX_PKT_RX_BURST and MAX_PKT_TX_BURST are updated from 64 to RTE_MBUF_BURST_SIZE_DEFAULT (32), but PKT_ENQUEUE remains hardcoded at 64 and PKT_DEQUEUE at 63. Now the enqueue size is 2× the Rx burst size, creating an inconsistency. If these values are related (and they appear to be — you burst Rx into an enqueue batch), they should be updated together or the relationship should be documented.
Warning: fprintf(stderr, ...) in example code for non-error messages
In examples/l3fwd/main.c, the added else branches print to stderr even when the user explicitly provided a value:

c
} else {
fprintf(stderr, "vector size set to (%" PRIu16 ")\n",
evt_rsrc->vector_size);
}
Using stderr for informational messages (not errors) is unconventional. This is example code so it's not critical, but printf or RTE_LOG would be more appropriate for confirming a user-supplied setting.
Warning: Duplicate MAX_PKT_BURST definition
In examples/link_status_interrupt/main.c, MAX_PKT_BURST is defined twice (lines 41 and 63 in the original). Both are being updated, but this pre-existing duplicate #define should ideally be cleaned up. Since the patch is already modifying both lines, removing the duplicate would be a good cleanup.




prev parent reply other threads:[~2026-02-21 16:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 8:24 [RFC 1/2] config: add optimal burst size configuration pbhagavatula
2025-11-26 8:24 ` [RFC 2/2] examples: use optimal burst size pbhagavatula
2025-11-26 9:57 ` [RFC 1/2] config: add optimal burst size configuration Morten Brørup
2025-11-26 10:58 ` Pavan Nikhilesh Bhagavatula
2025-11-26 11:00 ` Pavan Nikhilesh Bhagavatula
2026-02-02 9:57 ` Pavan Nikhilesh Bhagavatula
2025-11-27 22:01 ` Stephen Hemminger
2026-02-02 9:52 ` [EXTERNAL] " Pavan Nikhilesh Bhagavatula
2026-02-03 9:38 ` Morten Brørup
2026-02-20 23:07 ` [PATCH 1/2] config: add mbuf " pbhagavatula
2026-02-20 23:07 ` [PATCH 2/2] examples: use default mbuf burst size pbhagavatula
2026-02-21 16:26 ` Stephen Hemminger [this message]
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=20260221082646.4ec49f29@phoenix.local \
--to=stephen@networkplumber.org \
--cc=3chas3@gmail.com \
--cc=aman.deep.singh@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=anoobj@marvell.com \
--cc=bruce.richardson@intel.com \
--cc=chenbox@nvidia.com \
--cc=cristian.dumitrescu@intel.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=fanzhang.oss@gmail.com \
--cc=fengchengwen@huawei.com \
--cc=gakhil@marvell.com \
--cc=humin29@huawei.com \
--cc=jerinj@marvell.com \
--cc=jingjing.wu@intel.com \
--cc=john.mcnamara@intel.com \
--cc=kevin.laatz@intel.com \
--cc=konstantin.ananyev@huawei.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=nicolas.chautru@intel.com \
--cc=pbhagavatula@marvell.com \
--cc=radu.nicolau@intel.com \
--cc=sivaprasad.tummala@amd.com \
--cc=skori@marvell.com \
--cc=tomasz.kantecki@intel.com \
--cc=vfialko@marvell.com \
--cc=wisamm@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox